DETAILED ACTION
Status of the Claims
This action is in response to the application filed on January 8, 2024.
The claims were preliminarily amended on April 29, 2024.
Claims 2-21 are currently pending and have been examined.
Claim 1 has been cancelled.
Claims 2-21 are newly added.
The instant application is a continuation of Application 16/459,257, now US Patent 11,869,089.
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 .
Terminal Disclaimer
Examiner asserts that a Terminal Disclaimer is warranted due to the instant application 18/406,891 and US Patent 11,869,089 (formerly Application 16/459,257) sharing the same inventive entity and claim language which would otherwise result in a double patenting rejection.
Claim Interpretation – Broadest Reasonable Interpretation
9. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. see MPEP § 2103(I)(C); In re Johnson, 77 USPQ2d 1788 (Fed Cir 2006). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e. the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined.
As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. see MPEP §2013(I)(C). Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. see MPEP §2013(I)(C).
Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following italicized language is interpreted as not further limiting the scope of the claimed invention.
As in Claim 2:
wherein, in the active state, the mobile application receives telematics data from a sensor of the mobile device without maintaining a communication link with the first vehicle or a third-party telematics device;
As in Claims 12 and 18:
wherein, in the active state, the mobile application receives telematics data from a sensor of the mobile device without maintaining a communication link with the first vehicle or a third-party telematics device
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
10. Claims 2-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As currently recited, the independent claims do not appear to be properly supported by the specification to claim the invention in the manner claimed.
As in Claim 2: (and substantially similarly in Claims 12 and 18): the claim recites in part:
receiving, by a processor of a mobile device, a list of wireless communication addresses, each wireless communication address uniquely identifying a different respective vehicle;
receiving, by the processor and upon the mobile device entering into a threshold communication range of a first vehicle, a first wireless communication address of the first vehicle;
determining, by the processor, that the first wireless communication address matches a second wireless communication address included in the list of wireless communication addresses;
switching, by the processor and based on determining that the first wireless communication address matches the second wireless communications address, a mobile application operating on the mobile device from a background state to an active state;
Applicant’s specification discloses the following:
“Moreover, the one or more processors 112 may obtain the wireless communication address of the vehicle without establishing a communication link with the vehicle 102. For example, a device 104 may detect a signal from a wireless communication system (e.g., wireless communication system 128) embedded or otherwise associated with the vehicle 102 upon entering a threshold communication range with the wireless communication system 128. After detection, the device 104 may obtain the wireless communication address of the vehicle 102 from the wireless communication system 128 to perform further steps of the method described herein. However, in this example, the device 104 may simply obtain the address and never establish a communication link with the wireless communication system 128. This allows the device 104 to minimize its processing demand (i.e., increase efficiency by not establishing and/or maintaining a communication link with the vehicle 102) while effectively performing steps discussed herein.” (See Applicant Spec para 62)
“In other embodiments, the device 104 may obtain the wireless communication address once the device 104 is placed inside the vehicle 102. The application on the device 104 may also obtain the wireless communication address of the vehicle 102 after the application is switched to an active state by the device 104.” (See Applicant Spec para 63)
“At block 704, the device 104 may determine whether the wireless communication address corresponds to one of one or more known vehicles associated with an insured driver. For example, the device 104 may access information stored in its memory 114 or a remote database (e.g., memory 122, external databases 108) to identify each of the one or more vehicles associated with an insured driver. Each of the one or more vehicles may be identified via the application discussed herein and the insured driver’s user profile. In other words, the insured driver may have one or more vehicles previously identified and stored in the application under their user profile that the device 104 may use to authenticate any obtained wireless communication addresses. The device 104 may then compare the obtained wireless communication address with the listings of one or more known vehicles associated with the insured driver to check if any of the stored wireless communication addresses match the obtained wireless communication address. Block 704 may be performed by, for example, any or all of the one or more processors 112 of the device 104, any or all of the one or more processors 120 of the server 106, or any combination of both.” (See Applicant Spec para 64)
“Additionally or alternatively, the device 104 may compared the obtained wireless communication address to the addresses of one or more vehicles listed on an insurance policy. The device 104 may, for example, compare the information contained in an insurance policy associated with a user of the device 104 to the obtained wireless communication address. If the insurance policy does not describe or contain information describing a vehicle similar to that described by the obtained wireless communication address, the device 104 may not perform some or any further steps of the current method 700 with respect to the vehicle described by the obtained wireless communication address. Additionally or alternatively, if the insurance policy does not describe or contain information describing a similar vehicle to that described by the obtained wireless communication address, the device 104 may prompt a user to modify or adjust the insurance policy to include the vehicle represented by the obtained wireless communication address. On the other hand, if the obtained wireless communication address describes a vehicle identified in the insurance policy, the device 104 may perform some or all of the remaining steps of the method 700.” (See Applicant Spec para 65)
There is no apparent embodiment where the list of wireless communication addresses uniquely identifying a different respective vehicle can be received without the device accessing the information stored in its memory or from a remote database to identify vehicles identified with an insured driver, which is not recited. Further, there is no disclosure of the matching determinations without matching the second wireless communication address with the information in the stored list. Additionally, there is no disclosure of a procedure that switches a mobile application from a background state to an active state based on matching the wireless communication addresses.
Dependent Claims 3-11, 13-17 and 19-21 are further rejected as based upon a rejected base claim. Appropriate correction and clarification is required.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
11. Claim 4 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 4, which is dependent on Claim 2, recites the following:
wherein the list of communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, the method further comprising:
determining, by the processor, that the list of wireless communication addresses does not include the first wireless communication address;
based on determining that the list of wireless communication addresses does not include the first communication address, obtaining, by the processor, a verification that the first vehicle is covered by the insurance policy; and
responsive to receiving the verification, storing in the list, by the processor, the first wireless communication address.
Claim 2, from which Claim 4 depends recites receiving by a processor of a mobile device “a list of wireless communication addresses, each wireless communication address uniquely identifying a different respective vehicle; receiving, by the processor and upon the mobile device entering into a threshold communication range of a first vehicle, a first wireless communication address of the first vehicle; determining, by the processor, that the first wireless communication address matches a second wireless communication address included in the list of wireless communication addresses…”. The independent claim requires that the list includes the first vehicle’s wireless communication address matches a second wireless communication address included in the list of wireless communication address, it cannot then not include the first wireless communication address in Claim 4. This fails to further limit the claim and fails to include all limitations of the claim upon which it depends.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
12. Claims 2-21 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Claim 2 recites a method claim. Claim 12 recites a system claim. Claim 18 recites a non-transitory computer-readable medium claim.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 2 recites the abstract idea of determining a driving behavior. The idea is described by the following limitations:
receiving a list of wireless communication addresses;
receiving, a first wireless communication address of the first vehicle;
determining that the first wireless communication address matches a second wireless communication address included in the list of wireless communication addresses;
switching, based on determining that the first wireless communication address matches the second wireless communications address from a background state to an active state;
wherein in the active state, receiving data without maintaining a communication link with the first vehicle or a third-party device;
determining, based on the data, a driving behavior exhibited by the first vehicle.
Claims 12 and 18 recite the abstract idea of determining a driving behavior. The idea is described by the following limitations:
receive a list of wireless communication addresses, each wireless communication address uniquely identifying a different respective vehicle;
receive a first wireless communication address of the first vehicle;
determine that the first wireless communication address matches a second wireless communication address included in the list of wireless communication addresses;
switch, based on determining that the first wireless communication matches the second wireless communications address from a background state to an active state;
wherein, in the active state, receive data without maintaining a communication link with the first vehicle or a third party device;
determine, based on the data, a driving behavior exhibited by the first vehicle.
Under a BRI, the claims may reflect no more than determining a driving behavior by matching wireless communication addresses between a list of wireless communications addresses and a first vehicle and when the two addresses match, manually switching from a background state to an active state to receive data and using the data to determine a driving behavior exhibited by the first vehicle. This may be data that a user is collecting by switching to an active state that is used to determine a driving behavior.
As a result, the abstract ideas describe mental processes and certain methods of organizing human activity.
As to mental processes, the steps describe concepts performed in the human mind including an observation, evaluation, judgment and/or opinion (i.e., receiving a list of wireless communication addresses, each wireless communication address uniquely identifying a different respective vehicle; receive a first wireless communication address of a first vehicle; determine that there is a match between the first wireless communication address and a second wireless communication address included in the list of wireless communication addresses; switch based on the match from a background state to an active state.) These steps may be performing a mental process in a computer environment that recites limitations receiving, observing and evaluating information and with the exception of generic computer implemented steps, the claims themselves may be nothing more than a human observing and evaluating the contents of a list of wireless communication addresses, determining a match between a listed wireless communication address and a vehicle and switching manually from background to active state.
As to certain methods of organizing human activity, the steps involve managing personal behavior or relationships or interactions between people and ultimately fundamental economic principles or practices including insurance and mitigating risk (i.e., receive a list of wireless communication addresses, each wireless communication address uniquely identifying a different respective vehicle; receive a first wireless communication address of the first vehicle; determine that the first wireless communication address matches a second wireless communication address included in the list of wireless communication addresses; switch, based on a match between the first wireless communication address and the second wireless communications address from a background to active state and receive data to determine a driving behavior exhibited by the first vehicle). Applicant’s specification is clear that the determination of driving behavior is as to an insured driver and the list of communication addresses uniquely identifying a different respective vehicle are related to users listed as potential operators of a particular insured vehicle, thus is related to insurance and mitigating risk in insurance.
In the case of the instant claims, for example, the claims recite no more than receiving information that a subject user manually reviews, using generic computer technology to process, analyze, and present the received information and then based on the evaluation of a match, switch to an active state to receive data to determine a driving behavior based on received data. (Step 2A, Prong 1: Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
The claims do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Claim 2 recites a processor of a mobile device, a mobile application operating on the mobile device, and receiving telematics data from a sensor of the mobile device.
Claim 12 recites a processor associated with a mobile device; a non-transitory program memory storing instructions; a mobile application operating on the mobile device, and receiving telematics data from a sensor of the mobile device.
Claim 18 recites a tangible, non-transitory computer-readable medium storing instructions, a processor, a mobile device, a mobile application operating on the mobile device, and receiving telematics data from a sensor of the mobile device.
The claims recite a mobile device with a processor, a mobile application operating on the mobile device, a sensor of the mobile device, a non-transitory program memory storing instructions, which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Therefore, Claims 2, 12 and 18 are directed to an abstract idea without a practical application.(Step 2A, Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition); and vi) a web browser’s back and forward button functionality, Internet Patent Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015). (MPEP §2106.05(d)(II))
This listing is not meant to imply that all computer functions are well‐understood, routine, conventional activities, or that a claim reciting a generic computer component performing a generic computer function is necessarily ineligible. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. (MPEP §2106.05(d)(II) – emphasis added)
Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: recording a customer’s order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016); shuffling and dealing a standard deck of cards, In re Smith, 815 F.3d 816, 819, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016); restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017); presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; and arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015) (MPEP 2106.05(d))
Here, the steps are receiving or transmitting data over a network; storing and retrieving information in memory and electronically scanning or extracting data - all of which have been recognized by the courts as well-understood, routine and conventional functions.
The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry.
For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of “well-understood, routine, [and] conventional activities previously known to the industry.” Further, “the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
“In various embodiments, the mobile device 104 may execute computer-executable instructions, such as a mobile application, that allow the actions described herein to be implemented. For example, if the mobile device 104 is a smartphone, the user may capture data with the sensor array 118 to transmit through the network 110 to the server 106 for processing. The mobile device 104, and each of the computing devices referred to herein, may be any suitable computing device such as, but not limited to, a desktop computer, a laptop computer, a mobile phone such as a smart phone, a tablet, a phablet, smart glasses, other wearable computing device(s), etc.” (See Applicant Specification paragraph 22)
“The server may 106 may include a processor 120, a memory 122, and a transceiver 124. While referred to herein as a “processor,” in some embodiments the processor 120 includes two or more processors. The memory 122 may store computer-executable instructions, which may be executed by the processor 120. The memory 122 may include a driving history database 126. The driving history database 126 may contain historical data relating to a user’s operation of the vehicle 102.” (See Applicant Specification paragraph 23)
“In various embodiments, processors of the mobile device 104 and other devices, such as the server 106, may execute instructions to transmit data to, receive data from, or otherwise communicate with devices of the example system 100 via the network 110 as further described below. The network 110 may be or may include a network such as the Internet and/or any other type of suitable network (e.g., a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile network, a wired or wireless network, a private network, a virtual private network, etc.) The network 110 may also or alternatively be or include one or more cellular networks such as code division multiple access (CDMA) network, GSM, (Global System for Mobile Communications) network, WiMax (Worldwide Interoperability for Microwave Access) network, Long Term Evolution (LTE) network, etc.” (See Applicant Specification paragraph 26)
“The methods described in this application may include one or more functions or routines in the form of non-transitory computer-executable instructions that are stored in a tangible computer-readable storage medium and executed using a processor of a computing device (e.g., the mobile device 104, the server 106 and/or any other computing devices within the example system 100 in any suitable combination). The routines may be included as part of any of the modules described in relation to Figure 1 or as part of a module that is external to the system illustrated in Figure 1. For example, the methods or portions thereof may be part of a browser application(s) or an application(s) running on any of the devices in the example system 100 as a plug-in or other module of the browser application. Further, the methods may be employed as “software-as-a-service” to provide, for example, the mobile device 104, the server 106 and/or any other computing devices with access to the example system 100.” (See Applicant Specification paragraph 901
“Additionally, certain aspects are described herein as including logic or a number of functions, components, modules, blocks, or mechanisms. Functions may constitute either software modules (e.g., non-transitory code stored on a tangible machine-readable storage medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.” (See Applicant Specification paragraph 92)
“In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) to perform certain functions). A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed with a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.” (See Applicant Specification paragraph 93)
“Accordingly, the term hardware should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.” (See Applicant Specification paragraph 94)
Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Use of a computer in its ordinary capacity for tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to the abstract idea does not integrate a judicial exception into a practical application or provide significantly more. (See MPEP 2106.05(f))
The claims do not provide an inventive concept significantly more than the abstract idea. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The independent claims 2, 12 and 18 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent Claims 3-11, 13-17 and 19-21 further define the abstract idea that is presented in the respective Independent Claims 2, 12 and 18 and are further grouped as certain methods of organizing human activity and mental processes and are abstract for the same reasons and basis as presented above.
Dependent Claims 3, 13, and 20 provide further details of the first wireless communication address being a MAC address corresponding to a Bluetooth device of the first vehicle and is determined without establishing a communication link between the mobile device and the first vehicle. This is still describing comparing data of the communication addresses utilizing generic computer functions such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
Dependent Claim 4 further provides wherein the list of wireless communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, the method further comprising: determining, by the processor, that the list of wireless communication addresses does not include the first wireless communication address; based on determining that the list of wireless communication addresses does not include the first communication address, obtaining, by the processor, a verification that the first vehicle is covered by the insurance policy; and responsive to receiving the verification, storing in the list, by the processor, the first wireless communication address. This still describes mental processes and certain methods of organizing human activity.
Dependent Claim 5 provides further details identifying, by the processor and based on a first portion of the telematics data, a movement of the first vehicle indicative of a beginning of a vehicle trip; and identifying, by the processor and based on a second portion of the telematics data, a state of the first vehicle indicative of an end of the vehicle trip. This is still describing the data being identified by a processor as seen in the independent claim. This still describes certain methods of organizing human activity and mental processes (i.e., observing and evaluating data).
Dependent Claim 6 further provides wherein the state of the vehicle indicative of an end of the vehicle trip is identified based on the second portion of the telematics data indicating: a speed of zero for longer than a first threshold period of time, a deceleration immediately followed by a lack of acceleration for longer than a second threshold period of time, or no change in position for longer than a third threshold period of time. This is still describing the data being identified by a processor as seen in the independent claim. This still describes certain methods of organizing human activity and mental processes (i.e., observing and evaluating data).
Dependent Claim 7 further provides wherein the mobile application is switched from the background state to the active state based on identifying the movement indicative of the beginning of the vehicle trip. There is no particular mechanism claimed by which the movement is indicated.
This is still describing the data being identified by a processor as seen in the independent claim. This still describes certain methods of organizing human activity and mental processes (i.e., observing and evaluating data).
Dependent Claim 8 further provides wherein the mobile application collects the telematics data in a memory associated with the mobile device, the method further comprising based on identifying the end of the vehicle trip; transmitting, by the processor, from the memory to a remote server, the telematics data; and switching, by the processor, the mobile application from the active state to the background state. The additional element of transmitting data from the processor memory to a remote server is recited at a high level of generality and may be nothing more than a user transmitting data to a remote server at the conclusion of a trip and switching the mobile application to a background state. This still amounts to mere instructions to apply the exception using a generic computer component and still reflects mental processes and certain methods of organizing human activity.
Dependent Claim 9 further provides wherein the list of wireless communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, the method further comprising: updating, by the processor and based on the driving behavior exhibited by the first vehicle, a cost associated with the insurance policy. This still describes certain methods of organizing human activity and mental processes.
Dependent Claim 10 further provides accessing, by the processor and from a remote server, a driving history associated with the insurance policy; and displaying, by the processor and on a display associated with the first vehicle, the driving behavior and the driving history. This is receiving data by the processor of the mobile device from the remote server and displaying it. This still reflects mental processes and certain methods of organizing human activity.
Dependent Claim 11 further provides details regarding the sensor of the mobile device of Claim 2, reciting wherein the sensor includes at least one of a proximity sensor, an ambient light sensor, or a barometer, and the telematics data includes a set of values indicative of each one of speeding, braking, cornering, or mobile device usage. The additional details regarding the types of sensor that could be part of the mobile device are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The data received from the sensor is still describing the data being identified by a processor as seen in the independent claim. This still describes certain methods of organizing human activity and mental processes (i.e., observing and evaluating data).
Dependent Claim 14 further provides: identify, based on a first portion of the telematics data, a movement of the first vehicle indicative of a beginning of a vehicle trip, wherein the mobile application is switched from the background state to the active state further based on identifying the movement indicative of the beginning of the vehicle trip. There is no particular mechanism claimed by which the movement is indicated. This is still describing the data being identified by a processor as seen in the independent claim. This still describes certain methods of organizing human activity and mental processes (i.e., observing and evaluating data).
Dependent Claim 15 further recites wherein the mobile application collects the telematics data in a memory associated with the mobile device. This is no more than data collection by the mobile device. This is still describing certain methods of organizing human activity and mental processes.
Dependent Claim 16 further recites identify, based on the telematics data, a stopped state of the first vehicle indicating: a speed of zero for longer than a first threshold period of time, a deceleration immediately followed by a lack of acceleration for longer than a second threshold period of time, or no change in position for longer than a third threshold period of time; and based, on identifying the stopped state, switch the mobile application from the active state to the background state. This is still describing the data being identified by a processor as seen in the independent claim. This still describes certain methods of organizing human activity and mental processes (i.e., observing and evaluating data).
Dependent Claim 17 further recites wherein the list of wireless communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, and the instructions, when executed by the processor, further cause the processor to: update, based on the driving behavior, an aspect of the insurance policy, the aspect of the insurance policy including at least one of: a premium, a deductible, a discount, or a coverage level. This still describes certain methods of organizing human activity and mental processes.
Dependent Claim 19 further recites identify, based on a first portion of the telematics data, a movement of the first vehicle indicative of a beginning of a vehicle trip, wherein the mobile application is switched from the background state to the active state further based on identifying the movement indicative of the beginning of the vehicle trip; identify, based on a second portion of the telematics data, a stopped state of the first vehicle indicative of an end of the vehicle trip; and based on identifying the stopped state, switch the mobile application from the active state to the background state. There is no particular mechanism claimed by which the movement is indicated. This is still describing the data being identified by a processor as seen in the independent claim. This still describes certain methods of organizing human activity and mental processes (i.e., observing and evaluating data).
Dependent Claim 21 further recites wherein the list of wireless communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, and the instructions further causing the processor to: access, from a remote server, a driving history associated with the insurance policy; and display, on a display associated with the first vehicle, the driving behavior and the driving history. This is receiving data by the processor of the mobile device from the remote server and displaying it. This still reflects mental processes and certain methods of organizing human activity.
No further additional hardware components other than those found in the independent claims are recited, thus it is presumed that the claims are further utilizing the same generic systemization as presented in the independent claims. The claims do not recite additional elements that integrate the judicial exception into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Thus, Claims 2-21 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Examiner Note:
The manner in which the claims are currently recited do not clearly indicate the scope of the technical features it appears that Applicant wishes to bring forth. The claims (as seen in exemplary Claim 2) utilize a processor of a mobile device to receive data, however it appears that the mobile device must be running a mobile application of the insurer in order to receive the list of wireless communication addresses. It is not just a generic mobile device that can perform the steps as envisioned by the specification (in particular the process of Figure 7), it is the mobile device that is running a mobile application which has stored information related to the list of insured vehicles wireless communication addresses (not claimed) or from a remote database (also not claimed). Each of the one or more vehicles may be identified via the application and the insured driver’s user profile – thus in order to authenticate any obtained wireless communication addresses, both the wireless communication addresses from the stored list and the insured driver’s user profile must be used. (See Applicant Spec para 64)
The confirmation of the first wireless communication corresponding to the Bluetooth device is disclosed to be a confirmation from the insured driver. (See Applicant Spec para 66) The switching step is not disclosed to be based on the first wireless communication address matching a second wireless communication address, rather the device switches the mobile application to an activated state after one or more processors identify a first movement of the vehicle using analyzed data from the one or more sensors. The device may then activate the application to begin tracking a vehicle trip and then directly receives data from one or more sensors for use for vehicle trip analysis. (See Applicant Spec paras 70-71) In other embodiments, this may be performed by a back end server. (See Applicant Spec paras 71-72)
Applicant is encouraged to describe the interaction between the mobile device, mobile application, server, and sensors in a manner that reflects the processes disclosed in the specification and clearly capture the process by which the mobile application switches from a background to an active state and captures data directly from the sensor(s) as opposed to a reading where a user may be manually viewing wireless communication addresses and comparing them, then starting the mobile application on the mobile device to record data that is subsequently uploaded for analysis.
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.
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.
13. Claim(s) 2-21 are rejected under 35 U.S.C. 103 as being unpatentable over Bowne et al. (US 2017/0132712) (“Bowne”) in view of Fischer (US PG Pub. 2017/0041737) (“Fischer”) and further in view of Lawrie-Fussy et al (US PG Pub. 2017/0069144) (“Lawrie”)
Regarding Claim 2,
A computer-implemented method, comprising:
receiving, by a processor of a mobile device, a list of wireless communication addresses, each wireless communication address uniquely identifying a different respective vehicle; (See Bowne paras 8, 50-54, 68-69, 113-116, 184-188, 189-194, 200, 204, 210, Figs. 11B-K)
receiving, by the processor and upon the mobile device entering into a threshold communication range of a first vehicle, a first wireless communication address of the first vehicle; (See Bowne paragraphs 59, 189-191, 194 and 200)
determining, by the processor, that the first wireless communication address matches a second wireless communication address included in the list of wireless communication addresses; (See Bowne paragraphs 51-54, 59, 188-191, 193-194, 200, 203, Figs. 10-11E – BT pairing setup may be used to register or modify the vehicle being operated by completing the BT pairing; if the user successfully creates an account, the application will search for a signal to pair the mobile device to the vehicle, after pairing the user enters the additional data associating it with the insured driver to complete registration)
switching, by the processor and based on determining that the first wireless communication address matches the second wireless communications address, a mobile application operating on the mobile device from a background state to an active state, (See Bowne paras 59-62, 190-195, 203-205 – APP running on the smartphone may then turn itself on [activated state])
wherein, in the active state, the mobile application receives telematics data from a sensor of the mobile device without maintaining a communication link with the first vehicle or a third-party telematics device; and (See Bowne paragraphs 8, 40, 42, 44-47, 55, 59-61, 203-205 – APP collects data via sensors in the smartphone; sensors may collect one or more types of data regarding driving behavior and/or the driving environment)
determining, by the processor and based on the telematics data, a driving behavior exhibited by the first vehicle. (See Bowne paras 39-41, 46-48, 50-54, 59, 68-71, 177-183, 203-208)
Bowne discloses his invention as to a system and method for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data, the system comprising a mobile device, comprising: one or more sensors associated with the mobile device and configured to automatically collect vehicle operation data during a data collection session; a processor; a non-transitory storage medium; a display; a transmitter and a set of computer readable instructions stored in the non-transitory storage medium that when executed by the processor are configured to allow the mobile device to collect vehicle operation data and transmit the collected vehicle operation data; and a remote processing computer, comprising a server that receives collected vehicle operation data; a database that stores collected vehicle operation data; and a rating engine that determines a vehicle insurance premium based at least in part on collected vehicle operation data. (See Bowne Abstract)
According to certain embodiments of the invention, a smartphone based telematics technology solution may be implemented that requires no additional hardware or sensing equipment in an insured’s vehicle. (See Bowne paragraph 39 – smartphone based telematics requires no additional equipment in the insured’s vehicle) A mobile device equipped with software may capture and transmit the miles driven and vehicle dynamics (g-force events such as hard stops, sharp turns, fast accelerations, etc.) in an automated fashion. (See Bowne paragraph 39) Thus, individual drivers may collect and transmit driving behavior and use information to their insurance company via their mobile device. (See Bowne paragraph 39 – insured drivers may collect and transmit driving behavior and use information to the insurance company) Insurance customers may be incentivized to provide driving behavior and use information to their insurance company via their mobile device. (See Bowne paragraph 41)
A software application (“APP”) may be provided for operating systems such as those employed by iPhone, iPad and Android systems. (See Bowne paragraph 42) Once the APP is downloaded to the smartphone and launched for initial set up, no additional start/stop activities by the user may be required. (See Bowne paragraph 42) The APP may collect data using sensors in the smartphone to determine miles driven, location, time, and vehicle dynamics (g-force events such as hard stops, sharp turns, fast accelerations, etc.) (See Bowne paragraph 42) Computing infrastructure may be provided for receiving telematics data from customer smartphones in real time. (See Bowne paragraph 43)
In an embodiment, the APP may utilize sensors in a smartphone to automatically start and stop the application once initially setup on the smartphone where the APP may turn itself “on” as soon as the smartphone detects that it is in an automobile with its engine running. (See Bowne paragraph 44) Once detected, the APP may then turn itself on and begin tracking miles driven, location, time and vehicle dynamics (g-force data) and may be configured so that interaction with a driver is limited, such that the APP will run automatically on the smartphone after initial setup, wherein automatic start and stop capabilities may be accomplished using smartphone sensors. (See Bowne paragraph 44)
Mobile device may comprise any type of portable or mobile electronics device, such as for example a smartphone, a cell phone, a mobile telephone, personal digital assistant (PDA), laptop computer, tablet-style computer, or any other portable electronic device. (See Bowne paragraph 45) In some embodiments, the mobile device may be configured to provide one or more features of a driving analysis system such as (a) collection of driving data (e.g., data regarding driving behavior and/or the respective driving environment), (b) processing of collected driving data, and/or (c) providing collected driving data and/or processed driving data to a server or database via telecommunication or telematics. (See Bowne paragraph 46) Accordingly, the mobile device may include one or more sensors, a driving analysis application, a display and transmitters. (See Bowne paragraph 46)
The sensor(s) may collect one or more types of data regarding driving behavior and/or the driving environment. (See Bowne paragraph 47) For example, the mobile device may include a built-in accelerometer configured to detect acceleration in one or more directions, may include a GPS device or any other device for tracking the geographic location of the mobile device. (See Bowne paragraph 47) The mobile device may include sensors, systems or applications for collecting data regarding the driving environment, e.g., traffic congestion, weather conditions, roadway conditions, or driving infrastructure data. (See Bowne paragraph 47) In addition or alternatively, mobile device may collect certain driving data (e.g., driving behavior data and/or driving environment data) from sensors and/or devices external to the mobile device (e.g., speed sensors, blind spot information sensors, seat belt sensors, GPS device, etc.) (See Bowne paragraph 47)
The driving analysis application (“APP”) on the mobile device may process any or all of this driving data collected by the mobile device and/or data received at the mobile device from external sources to calculate one or more driving behavior metrics and/or scores based on such collected data and display the processed data (See Bowne paragraphs 48-49)
An insurance company may access driving behavior data collected/processed by a mobile device and use such data for risk analysis of a driver and determining appropriate insurance products or premiums for the driver according to such risk analysis. (See Bowne paragraph 50)
Bowne discloses the example components of the mobile device relevant to the driving analysis system discussed and discloses that the mobile device may include a memory (which may comprise any one or more devices suitable for storing electronic data [one or more memories], a processor [which may include a variety of different processors or any other suitable processor(s) [one or more processors], one or more sensors, a display and input/output devices. (See Bowne paragraphs 51-54)
Figure 10 of Bowne provides a flowchart for a driving analysis application where the application launches on a mobile device and splashes an introductory page publishing the name of the application and appropriate logos to identify the application. (See Bowne paragraph 193) The application queries the user to determine whether the user is registered. (See Bowne paragraph 193) If the user is not registered, the application will prompt the user to create an account. (See Bowne paragraph 193) When the user is registering for the first time, the user may enter details like username; password; vehicle make; vehicle year; vehicle model; and/or vehicle odometer reading. (See Bowne paragraph 193) If the account is successfully created, the user may be directed to a main menu that may have options including a Bluetooth pairing setup for completing the registration or modifying the car which is being used, which when successful, transmits the data to a server which may include the Bluetooth Mac address. (See Bowne paragraph 194)
In reference to Figures 11A-K, Bowne discloses screen shots of the application user interface related to completing the registration and discloses that after Bluetooth pairing, a Vehicle screen is displayed to the user to enter the year, make, model and odometer reading of the paired vehicle and once paired with the vehicle, the registration is complete. (See Bowne paragraph 200, Figs. 11a-k – Bluetooth pairing of vehicle matched to the vehicle of an insured driver using the app)
Figure 12 illustrates a flowchart for collection and analysis of vehicle use data where when the user starts the engine of the vehicle, a Bluetooth connection is made between the mobile device and the vehicle which when successful, the application begins logging data which is collected and sent to the server of the remote data storage system when the engine turns off and the application stops logging data. (See Bowne paragraph 203) According to different aspects of the invention, software may reside on the mobile device in the application to perform various calculations and manipulation of data, or software may reside on a remote processing computer or a remote data storage system. (See Bowne paragraph 204)
A rating engine according to embodiments of the invention may be used to generate or calculate user-based insurance premiums which may be applied prospectively or retrospectively. (See Bowne paragraph 206) Based on the collected data, a previously paid insurance premium may be adjusted by providing a rebate for low risk driving behaviors or charging a surcharge for high risk driving behaviors. (See Bowne paragraph 206 – relates to an already insured driver) A rating engine may be used to calculate an insurance premium based on data collected from the mobile device. (See Bowne paragraph 207) The individual factors may be placed in context with other known information about the insured user to increase the predictive power of the automated rating engine to set an appropriate insurance premium for the particular insured user. (See Bowne paragraph 207 – insured user) Insurance premiums are typically calculated based on actuarial classifications which may include vehicle type, age, equipment, etc. and data collected from the mobile device may be used to supplement these actuarial classifications to calculate an insurance premium. (See Bowne paragraph 207 – data related to known vehicles are associated with the insured to calculate insurance premiums).
While Bowne teaches the invention as disclosed and does teach obtaining a wireless communication address of an insured driver and that after registration the recognized Bluetooth connection is made by the APP when the driver and their mobile device are in the vehicle, Fischer discloses creation of a database on the driver’s personal device that associates the subject’s driven vehicle’s Bluetooth device MAC address to the driver’s personal device without establishing a communication link and association of a personal device with a driver in a known vehicle. Further, while Bowne discloses collection of a plurality of vehicle telematics data, Fischer further discloses additional types of collected telematics data related to the invention as presented.
Fischer discloses his invention as to a method and system for detecting unsafe or suspect activities such as distracted driving associated with distracted driving events to the road type, vehicle speed and acceleration at the time of the distracted driving event. (See Fischer paragraph 4) The system employs a smartphone application coupled with a central server that computes driver safety scores which relate time of day, road type, vehicle speed, vehicle acceleration (positive, negative and lateral) and distracted driving using the Cauchy distribution equation. (See Fischer paragraph 4)
The disclosed method for tracking driving habits includes associating a personal device with a driver in a vehicle, determining that the driver is engaging in a suspect activity while driving, comparing the suspect activity with a severity scale indicative of a relative risk of the activity, computing a score based on the comparison and reporting the determined suspect activity and the score to a repository for accumulating a driving history of a driver. (See Fischer paragraph 8) The method may include more specific operations depending on the type of suspect event, for example, the method for tracking driving events may include determining, via a personal device associated with the driver in a vehicle, a speed of the vehicle. (See Fischer paragraph 8)
Fischer discloses that distracted driving is any activity that could divert a person’s attention away from the primary task of driving, particular interactive apps because text messaging, email usage and web browsing require visual, manual and cognitive attention from the driver, they are by far the most alarming distractions. (See Fischer paragraph 18) The method and system for detecting distracted driving associates distracted driving events to the road type, vehicle speed and vehicle acceleration (positive, negative and lateral) at the time of the distracted driving event and using the Cauchy distribution equation, provides summary and detail reports of driving scores and distracted driving events to concerned parties including insurance companies and vehicle owners. (See Fischer paragraph 19)
Fischer discloses a computing environment suitable for all of the disclosed configurations of the invention where the monitored driving environment, a driving evaluator application (app) executes on a personal electronic device such as a mobile phone or smartphone and the app gathers data and events pertaining to driving performance and is associated with a driver of a vehicle. (See Fischer paragraph 29 and Fig. 1) The personal device includes sensors and components for sensing the data indicative of the suspect activity, such as a GPS interface, accelerometer, telematics interface and ambient light sensor. (See Fischer paragraphs 32-33)
The method for tracking driving habits includes associating a personal device with a driver in a vehicle which may include associating the personal device with the vehicle by identifying a positioning device disposed in the vehicle of a monitored driver, in which the positioning device is a telematics unit (appliance) responsive to the personal device. (See Fischer paragraph 55) Applicant invocation may be facilitated by near field communication (NFC) based on proximity to the vehicle, such as the application is invoked automatically each time the driver enters the vehicle. (See Fischer paragraph 55 and FIGS. 5A-C – application is invoked based on proximity to vehicle and invoked automatically each time the driver enters the vehicle [detection by mobile device based on proximity when driver enters the vehicle)
Communications between the personal device and the telematics appliance includes at least one of Bluetooth, BLE, WiFi, NFC and transmissions under IEEE 802.11, or other suitable wired or wireless mechanism. (See Fischer paragraph 71) The personal device is a typical cellphone or smartphone carried by the user and may include any suitable phone, tablet, laptop, watch, or other computing and telecommunications device specific to the user and adapted for wireless electronic communication and execution of apps defined by preprogrammed computing instructions. (See Fischer paragraph 73 – mobile device)
In operation, the disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s VIN to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s VIN to the driver’s personal device. (See Fischer paragraph 75) An alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Bluetooth device serial number (BD_ADDR or MAC address) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Bluetooth device serial number to the driver’s personal device. (See Fischer paragraphs 75-76 – obtained MAC address without establishing a communication link to the vehicle, without pairing)
A third alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Wifi device serial number (commonly called Media Access Control (MAC) address) or unique Wifi device Service Set Identifier (SSID) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Wifi Media Access Control (MAC) address to the driver’s personal device. (See Fischer paragraph 77)
Upon driver invocation of the monitoring app on their device, identification of the user device may include receiving the VIN, BD_ADDR, MAC address or SSID to ascertain if the user’s personal device is being used within the subject driven vehicle. (See Fischer paragraphs 78-79 – determining if wireless communication address corresponds to a known vehicle of insured driver, stores list of vehicles including VIN, MAC, BD_ADDR, etc. in personal device database or server database)
In operation, a scenario may be anticipated where multiple passengers, each with a personal device, is invoked. (See Fischer paragraph 79) Distracted driving can be ascertained when a personal device is invoked from a paired vehicle associated with that device, since only the regular operator would be paired. (See Fischer paragraph 79 – the pairing indicates that the known operator [insured driver] corresponds to the insured vehicle)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne with the method and system for detecting unsafe or suspect activities such as distracted driving that is associated to road type, vehicle speed and vehicle acceleration as taught by Fischer in order to use such additional data in the risk analysis of a driver to determine appropriate insurance products or premiums for a driver based on the collected data on driving behavior.
While Bowne in view of Fischer, as disclosed above do disclose that the app populates and saves information regarding vehicles covered and connects the tracking of vehicles to those noted in the app implying that there is a list of vehicles covered by an insurance policy of the insured driver and discloses pairing to the vehicle Bluetooth which would match the wireless communication addresses, Bowne in view of Fischer does not disclose a list per se of one of more vehicles covered by an insurance policy of an insured driver and matching first wireless communication address to the second wireless communication address.
Lawrie discloses his invention as to a monitoring apparatus that provides vehicle telematics data where the monitoring apparatus includes a sensor for sensing vehicle and engine motion induced vibration in part of a vehicle and for generating vibration associated data where the sensor is coupled to part of the vehicle. (See Lawrie Abstract)
The monitoring device preferably uses short range wireless radio technology such as Bluetooth, and is provided with a clock. (See Lawrie paragraph 66) The communication apparatus may be arranged to operate with a wireless communication technology and may be arranged, for example, to operate with a wireless communication technology complying with Bluetooth low energy protocol. (See Lawrie paragraph 66) The invention may also provide a system including the monitoring device, a portable smart device configured for communication with the device and a remote server configured to communicate with the smart device to obtain the data. (See Lawrie paragraph 67)
Lawrie further discloses a smart user communication device comprising a smart device application (“app”) for communicating with the monitoring device and a secure remote server for handling analysis, reporting and alerting configured to communicate with the smart device 26 via the app 28 and a communication network 13 such as the internet. (See Lawrie paragraph 87 and Fig. 1) In an exemplary system, the monitoring device is configured to monitor vehicle usage data and to wireless transmit this data to the app installed on the smart user communication device, here a smartphone that is configured to transmit the received vehicle usage data via the app over the internet to the secure remote server. (See Lawrie paragraph 87) The monitoring device is arranged to use short range radio technology such as Bluetooth. (See Lawrie paragraph 89)
The secure remote server may belong to an insurance company and would allow the insurance company to track the driving behavior of a driver and establish a risk profile based on the driving behavior for that driver, for insurance purposes. (See Lawrie paragraph 88)
Typically, the smart phone can operate with a wireless communication technology of Bluetooth, BLE or Bluetooth Smart protocol and can typically make use of GPS. (See Lawrie paragraph 90)
The app will typically be installed by the user on the smart-phone. (See Lawrie paragraph 91) The app comprises a ‘scan’ mode in which it causes the smart-phone to scan for nearby monitoring devices and to provide a list of permissible devices seen by the user. (See Lawrie paragraph 92) The user can then select the appropriate monitoring device from the list using the app and assign the correct monitoring device to the correct vehicle. (See Lawrie paragraph 92) The device is able to reject communication requests from an unassociated app from another user. (See Lawrie paragraph 92)
Beneficially, the monitoring device also has a mode for providing an indication to the user to confirm that the app is indeed communicating with the monitoring device that the user believes it to be. (See Lawrie paragraph 93) This is particular useful for situations where a new or previously un-paired monitoring device is to be utilized, especially when there are a number of potential choices in the vicinity (e.g., multi-card insurance, where the owner is pairing all of their vehicle/tags at once.) (See Lawrie paragraph 93 – list of insured vehicles)
Once the app and the monitoring device are communicating the app requests that the user confirms that the monitoring device is attached to the vehicle that is associated with the user in the app or requests that the user identify the vehicle to which the monitoring device is attached either by selecting from a list of vehicles provided on a selection page in the app (if multiple vehicles are associated with the user in the app) or manually if the app does not currently have the details of the vehicle. (See Lawrie paragraph 95 – list of vehicles associated with the user in the app, matches the communication between the app and the monitoring device)
Once the app has completed linking the monitoring device to the correct vehicle, no further user setup is required and the monitoring device is able to auto-configure its own internal algorithms. (See Lawrie paragraph 96) The app provides a mode which can be consulted by the user in order to ascertain whether the monitoring device is “live”. (See Lawrie paragraph 96) The monitoring device remains in an ‘on’ state until such a time as its power source runs out, in order to save energy, the monitoring device may provide no visible signs of the ‘on’ state. (See Lawrie paragraph 96)
The app is configured to run in the background on the smart-phone. (See Lawrie paragraph 97) This is advantageous as there is no need to actively start the app prior to driving. (See Lawrie paragraph 97) The app is configured to interrogate the monitoring device without any need for user interaction with the app. (See Lawrie paragraph 97)
The communication interface of the monitoring device may use Bluetooth, Bluetooth Smart, NFC, Wi-Fi, etc., or any suitable wireless protocol. (See Lawrie paragraph 110) The interface is configured to send an ‘advertise’ signal periodically which can be detected by a corresponding device of, for example, a driver’s smart-phone or other smart device and is configured to establish a connection with the smart-phone for the transfer of data. (See Lawrie paragraph 110) The system of the invention also provides a smartphone application which can be installed on the smart-phone for use in interrogating the monitoring device. (See Lawrie paragraph 110) The monitoring device may include one or more security components for confirming the authenticity of the device to other systems, such as a smartphone or server. (See Lawrie paragraph 202) Digital keys used by this security component(s) may include symmetric keys for short radio likes to another radio-enabled device (for instance a bluetooth link key), symmetric keys for links with multiple hops such as via a smartphone to a server, or public/private keypairs with associated algorithms to apply digital signatures to data generated by the device. (See Lawrie paragraph 202)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne in view of Fischer with disclosure of providing telematics via a monitoring app that requests confirmation of communications using a list of vehicles that are insured by an owner as taught by Lawrie in order to confirm that the correct vehicle is being monitored.
Regarding Claim 12, Bowne discloses the following:
A system, comprising:
a processor associated with a mobile device; and (See Bowne paragraphs 51-54 - mobile device includes a processor which may include any other suitable processor(s))
a non-transitory program memory storing instructions that, when executed by the processor, cause the processor to: (See Bowne Abstract and paragraphs 8, 12, 51-54, 58, 115, Cl. 31)
receive a list of wireless communication addresses, each wireless communication address uniquely identifying a different respective vehicle; (See Bowne paras 8, 50-54, 68-69, 113-116, 184-188, 189-194, 200, 204, 210, Figs. 11B-K)
receive, upon the mobile device entering into a threshold communication range of a first vehicle, a first wireless communication address of the first vehicle; (See Bowne paragraphs 59, 189-191, 194 and 200)
determine that the first wireless communication address matches a second wireless communication address included in the list of wireless communication addresses; (See Bowne paragraphs 51-54, 59, 188-191, 193-194, 200, 203, Figs. 10-11E – BT pairing setup may be used to register or modify the vehicle being operated by completing the BT pairing; if the user successfully creates an account, the application will search for a signal to pair the mobile device to the vehicle, after pairing the user enters the additional data associating it with the insured driver to complete registration)
switch, based on determining that the first wireless communication address matches the second wireless communications address, a mobile application operating on the mobile device from a background state to an active state, (See Bowne paras 59-62, 190-195, 203-205 – APP running on the smartphone may then turn itself on [activated state])
wherein, in the active state, the mobile application receives telematics data from a sensor of the mobile device without maintaining a communication link with the first vehicle or a third-party telematics device; and (See Bowne paragraphs 8, 40, 42, 44-47, 55, 59-61, 203-205 – APP collects data via sensors in the smartphone; sensors may collect one or more types of data regarding driving behavior and/or the driving environment)
determine, based on the telematics data, a driving behavior exhibited by the first vehicle. (See Bowne paras 39-41, 46-48, 50-54, 59, 68-71, 177-183, 203-208)
Bowne discloses his invention as to a system and method for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data, the system comprising a mobile device, comprising: one or more sensors associated with the mobile device and configured to automatically collect vehicle operation data during a data collection session; a processor; a non-transitory storage medium; a display; a transmitter and a set of computer readable instructions stored in the non-transitory storage medium that when executed by the processor are configured to allow the mobile device to collect vehicle operation data and transmit the collected vehicle operation data; and a remote processing computer, comprising a server that receives collected vehicle operation data; a database that stores collected vehicle operation data; and a rating engine that determines a vehicle insurance premium based at least in part on collected vehicle operation data. (See Bowne Abstract)
According to certain embodiments of the invention, a smartphone based telematics technology solution may be implemented that requires no additional hardware or sensing equipment in an insured’s vehicle. (See Bowne paragraph 39 – smartphone based telematics requires no additional equipment in the insured’s vehicle) A mobile device equipped with software may capture and transmit the miles driven and vehicle dynamics (g-force events such as hard stops, sharp turns, fast accelerations, etc.) in an automated fashion. (See Bowne paragraph 39) Thus, individual drivers may collect and transmit driving behavior and use information to their insurance company via their mobile device. (See Bowne paragraph 39 – insured drivers may collect and transmit driving behavior and use information to the insurance company) Insurance customers may be incentivized to provide driving behavior and use information to their insurance company via their mobile device. (See Bowne paragraph 41)
A software application (“APP”) may be provided for operating systems such as those employed by iPhone, iPad and Android systems. (See Bowne paragraph 42) Once the APP is downloaded to the smartphone and launched for initial set up, no additional start/stop activities by the user may be required. (See Bowne paragraph 42) The APP may collect data using sensors in the smartphone to determine miles driven, location, time, and vehicle dynamics (g-force events such as hard stops, sharp turns, fast accelerations, etc.) (See Bowne paragraph 42) Computing infrastructure may be provided for receiving telematics data from customer smartphones in real time. (See Bowne paragraph 43)
In an embodiment, the APP may utilize sensors in a smartphone to automatically start and stop the application once initially setup on the smartphone where the APP may turn itself “on” as soon as the smartphone detects that it is in an automobile with its engine running. (See Bowne paragraph 44) Once detected, the APP may then turn itself on and begin tracking miles driven, location, time and vehicle dynamics (g-force data) and may be configured so that interaction with a driver is limited, such that the APP will run automatically on the smartphone after initial setup, wherein automatic start and stop capabilities may be accomplished using smartphone sensors. (See Bowne paragraph 44)
Mobile device may comprise any type of portable or mobile electronics device, such as for example a smartphone, a cell phone, a mobile telephone, personal digital assistant (PDA), laptop computer, tablet-style computer, or any other portable electronic device. (See Bowne paragraph 45) In some embodiments, the mobile device may be configured to provide one or more features of a driving analysis system such as (a) collection of driving data (e.g., data regarding driving behavior and/or the respective driving environment), (b) processing of collected driving data, and/or (c) providing collected driving data and/or processed driving data to a server or database via telecommunication or telematics. (See Bowne paragraph 46) Accordingly, the mobile device may include one or more sensors, a driving analysis application, a display and transmitters. (See Bowne paragraph 46)
The sensor(s) may collect one or more types of data regarding driving behavior and/or the driving environment. (See Bowne paragraph 47) For example, the mobile device may include a built-in accelerometer configured to detect acceleration in one or more directions, may include a GPS device or any other device for tracking the geographic location of the mobile device. (See Bowne paragraph 47) The mobile device may include sensors, systems or applications for collecting data regarding the driving environment, e.g., traffic congestion, weather conditions, roadway conditions, or driving infrastructure data. (See Bowne paragraph 47) In addition or alternatively, mobile device may collect certain driving data (e.g., driving behavior data and/or driving environment data) from sensors and/or devices external to the mobile device (e.g., speed sensors, blind spot information sensors, seat belt sensors, GPS device, etc.) (See Bowne paragraph 47)
The driving analysis application (“APP”) on the mobile device may process any or all of this driving data collected by the mobile device and/or data received at the mobile device from external sources to calculate one or more driving behavior metrics and/or scores based on such collected data and display the processed data (See Bowne paragraphs 48-49)
An insurance company may access driving behavior data collected/processed by a mobile device and use such data for risk analysis of a driver and determining appropriate insurance products or premiums for the driver according to such risk analysis. (See Bowne paragraph 50)
Bowne discloses the example components of the mobile device relevant to the driving analysis system discussed and discloses that the mobile device may include a memory (which may comprise any one or more devices suitable for storing electronic data [one or more memories], a processor [which may include a variety of different processors or any other suitable processor(s) [one or more processors], one or more sensors, a display and input/output devices. (See Bowne paragraphs 51-54)
Figure 10 of Bowne provides a flowchart for a driving analysis application where the application launches on a mobile device and splashes an introductory page publishing the name of the application and appropriate logos to identify the application. (See Bowne paragraph 193) The application queries the user to determine whether the user is registered. (See Bowne paragraph 193) If the user is not registered, the application will prompt the user to create an account. (See Bowne paragraph 193) When the user is registering for the first time, the user may enter details like username; password; vehicle make; vehicle year; vehicle model; and/or vehicle odometer reading. (See Bowne paragraph 193) If the account is successfully created, the user may be directed to a main menu that may have options including a Bluetooth pairing setup for completing the registration or modifying the car which is being used, which when successful, transmits the data to a server which may include the Bluetooth Mac address. (See Bowne paragraph 194)
In reference to Figures 11A-K, Bowne discloses screen shots of the application user interface related to completing the registration and discloses that after Bluetooth pairing, a Vehicle screen is displayed to the user to enter the year, make, model and odometer reading of the paired vehicle and once paired with the vehicle, the registration is complete. (See Bowne paragraph 200, Figs. 11a-k – Bluetooth pairing of vehicle matched to the vehicle of an insured driver using the app)
Figure 12 illustrates a flowchart for collection and analysis of vehicle use data where when the user starts the engine of the vehicle, a Bluetooth connection is made between the mobile device and the vehicle which when successful, the application begins logging data which is collected and sent to the server of the remote data storage system when the engine turns off and the application stops logging data. (See Bowne paragraph 203) According to different aspects of the invention, software may reside on the mobile device in the application to perform various calculations and manipulation of data, or software may reside on a remote processing computer or a remote data storage system. (See Bowne paragraph 204)
A rating engine according to embodiments of the invention may be used to generate or calculate user-based insurance premiums which may be applied prospectively or retrospectively. (See Bowne paragraph 206) Based on the collected data, a previously paid insurance premium may be adjusted by providing a rebate for low risk driving behaviors or charging a surcharge for high risk driving behaviors. (See Bowne paragraph 206 – relates to an already insured driver) A rating engine may be used to calculate an insurance premium based on data collected from the mobile device. (See Bowne paragraph 207) The individual factors may be placed in context with other known information about the insured user to increase the predictive power of the automated rating engine to set an appropriate insurance premium for the particular insured user. (See Bowne paragraph 207 – insured user) Insurance premiums are typically calculated based on actuarial classifications which may include vehicle type, age, equipment, etc. and data collected from the mobile device may be used to supplement these actuarial classifications to calculate an insurance premium. (See Bowne paragraph 207 – data related to known vehicles are associated with the insured to calculate insurance premiums).
While Bowne teaches the invention as disclosed and does teach obtaining a wireless communication address of an insured driver and that after registration the recognized Bluetooth connection is made by the APP when the driver and their mobile device are in the vehicle, Fischer discloses creation of a database on the driver’s personal device that associates the subject’s driven vehicle’s Bluetooth device MAC address to the driver’s personal device without establishing a communication link and association of a personal device with a driver in a known vehicle. Further, while Bowne discloses collection of a plurality of vehicle telematics data, Fischer further discloses additional types of collected telematics data related to the invention as presented.
Fischer discloses his invention as to a method and system for detecting unsafe or suspect activities such as distracted driving associated with distracted driving events to the road type, vehicle speed and acceleration at the time of the distracted driving event. (See Fischer paragraph 4) The system employs a smartphone application coupled with a central server that computes driver safety scores which relate time of day, road type, vehicle speed, vehicle acceleration (positive, negative and lateral) and distracted driving using the Cauchy distribution equation. (See Fischer paragraph 4)
The disclosed method for tracking driving habits includes associating a personal device with a driver in a vehicle, determining that the driver is engaging in a suspect activity while driving, comparing the suspect activity with a severity scale indicative of a relative risk of the activity, computing a score based on the comparison and reporting the determined suspect activity and the score to a repository for accumulating a driving history of a driver. (See Fischer paragraph 8) The method may include more specific operations depending on the type of suspect event, for example, the method for tracking driving events may include determining, via a personal device associated with the driver in a vehicle, a speed of the vehicle. (See Fischer paragraph 8)
Fischer discloses that distracted driving is any activity that could divert a person’s attention away from the primary task of driving, particular interactive apps because text messaging, email usage and web browsing require visual, manual and cognitive attention from the driver, they are by far the most alarming distractions. (See Fischer paragraph 18) The method and system for detecting distracted driving associates distracted driving events to the road type, vehicle speed and vehicle acceleration (positive, negative and lateral) at the time of the distracted driving event and using the Cauchy distribution equation, provides summary and detail reports of driving scores and distracted driving events to concerned parties including insurance companies and vehicle owners. (See Fischer paragraph 19)
Fischer discloses a computing environment suitable for all of the disclosed configurations of the invention where the monitored driving environment, a driving evaluator application (app) executes on a personal electronic device such as a mobile phone or smartphone and the app gathers data and events pertaining to driving performance and is associated with a driver of a vehicle. (See Fischer paragraph 29 and Fig. 1) The personal device includes sensors and components for sensing the data indicative of the suspect activity, such as a GPS interface, accelerometer, telematics interface and ambient light sensor. (See Fischer paragraphs 32-33)
The method for tracking driving habits includes associating a personal device with a driver in a vehicle which may include associating the personal device with the vehicle by identifying a positioning device disposed in the vehicle of a monitored driver, in which the positioning device is a telematics unit (appliance) responsive to the personal device. (See Fischer paragraph 55) Applicant invocation may be facilitated by near field communication (NFC) based on proximity to the vehicle, such as the application is invoked automatically each time the driver enters the vehicle. (See Fischer paragraph 55 and FIGS. 5A-C – application is invoked based on proximity to vehicle and invoked automatically each time the driver enters the vehicle [detection by mobile device based on proximity when driver enters the vehicle)
Communications between the personal device and the telematics appliance includes at least one of Bluetooth, BLE, WiFi, NFC and transmissions under IEEE 802.11, or other suitable wired or wireless mechanism. (See Fischer paragraph 71) The personal device is a typical cellphone or smartphone carried by the user and may include any suitable phone, tablet, laptop, watch, or other computing and telecommunications device specific to the user and adapted for wireless electronic communication and execution of apps defined by preprogrammed computing instructions. (See Fischer paragraph 73 – mobile device)
In operation, the disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s VIN to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s VIN to the driver’s personal device. (See Fischer paragraph 75) An alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Bluetooth device serial number (BD_ADDR or MAC address) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Bluetooth device serial number to the driver’s personal device. (See Fischer paragraphs 75-76 – obtained MAC address without establishing a communication link to the vehicle, without pairing)
A third alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Wifi device serial number (commonly called Media Access Control (MAC) address) or unique Wifi device Service Set Identifier (SSID) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Wifi Media Access Control (MAC) address to the driver’s personal device. (See Fischer paragraph 77)
Upon driver invocation of the monitoring app on their device, identification of the user device may include receiving the VIN, BD_ADDR, MAC address or SSID to ascertain if the user’s personal device is being used within the subject driven vehicle. (See Fischer paragraphs 78-79 – determining if wireless communication address corresponds to a known vehicle of insured driver, stores list of vehicles including VIN, MAC, BD_ADDR, etc. in personal device database or server database)
In operation, a scenario may be anticipated where multiple passengers, each with a personal device, is invoked. (See Fischer paragraph 79) Distracted driving can be ascertained when a personal device is invoked from a paired vehicle associated with that device, since only the regular operator would be paired. (See Fischer paragraph 79 – the pairing indicates that the known operator [insured driver] corresponds to the insured vehicle)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne with the method and system for detecting unsafe or suspect activities such as distracted driving that is associated to road type, vehicle speed and vehicle acceleration as taught by Fischer in order to use such additional data in the risk analysis of a driver to determine appropriate insurance products or premiums for a driver based on the collected data on driving behavior.
While Bowne in view of Fischer, as disclosed above do disclose that the app populates and saves information regarding vehicles covered and connects the tracking of vehicles to those noted in the app implying that there is a list of vehicles covered by an insurance policy of the insured driver and discloses pairing to the vehicle Bluetooth which would match the wireless communication addresses, Bowne in view of Fischer does not disclose a list per se of one of more vehicles covered by an insurance policy of an insured driver and matching first wireless communication address to the second wireless communication address.
Lawrie discloses his invention as to a monitoring apparatus that provides vehicle telematics data where the monitoring apparatus includes a sensor for sensing vehicle and engine motion induced vibration in part of a vehicle and for generating vibration associated data where the sensor is coupled to part of the vehicle. (See Lawrie Abstract)
The monitoring device preferably uses short range wireless radio technology such as Bluetooth, and is provided with a clock. (See Lawrie paragraph 66) The communication apparatus may be arranged to operate with a wireless communication technology and may be arranged, for example, to operate with a wireless communication technology complying with Bluetooth low energy protocol. (See Lawrie paragraph 66) The invention may also provide a system including the monitoring device, a portable smart device configured for communication with the device and a remote server configured to communicate with the smart device to obtain the data. (See Lawrie paragraph 67)
Lawrie further discloses a smart user communication device comprising a smart device application (“app”) for communicating with the monitoring device and a secure remote server for handling analysis, reporting and alerting configured to communicate with the smart device 26 via the app 28 and a communication network 13 such as the internet. (See Lawrie paragraph 87 and Fig. 1) In an exemplary system, the monitoring device is configured to monitor vehicle usage data and to wireless transmit this data to the app installed on the smart user communication device, here a smartphone that is configured to transmit the received vehicle usage data via the app over the internet to the secure remote server. (See Lawrie paragraph 87) The monitoring device is arranged to use short range radio technology such as Bluetooth. (See Lawrie paragraph 89)
The secure remote server may belong to an insurance company and would allow the insurance company to track the driving behavior of a driver and establish a risk profile based on the driving behavior for that driver, for insurance purposes. (See Lawrie paragraph 88)
Typically, the smart phone can operate with a wireless communication technology of Bluetooth, BLE or Bluetooth Smart protocol and can typically make use of GPS. (See Lawrie paragraph 90)
The app will typically be installed by the user on the smart-phone. (See Lawrie paragraph 91) The app comprises a ‘scan’ mode in which it causes the smart-phone to scan for nearby monitoring devices and to provide a list of permissible devices seen by the user. (See Lawrie paragraph 92) The user can then select the appropriate monitoring device from the list using the app and assign the correct monitoring device to the correct vehicle. (See Lawrie paragraph 92) The device is able to reject communication requests from an unassociated app from another user. (See Lawrie paragraph 92)
Beneficially, the monitoring device also has a mode for providing an indication to the user to confirm that the app is indeed communicating with the monitoring device that the user believes it to be. (See Lawrie paragraph 93) This is particular useful for situations where a new or previously un-paired monitoring device is to be utilized, especially when there are a number of potential choices in the vicinity (e.g., multi-card insurance, where the owner is pairing all of their vehicle/tags at once.) (See Lawrie paragraph 93 – list of insured vehicles)
Once the app and the monitoring device are communicating the app requests that the user confirms that the monitoring device is attached to the vehicle that is associated with the user in the app or requests that the user identify the vehicle to which the monitoring device is attached either by selecting from a list of vehicles provided on a selection page in the app (if multiple vehicles are associated with the user in the app) or manually if the app does not currently have the details of the vehicle. (See Lawrie paragraph 95 – list of vehicles associated with the user in the app, matches the communication between the app and the monitoring device)
Once the app has completed linking the monitoring device to the correct vehicle, no further user setup is required and the monitoring device is able to auto-configure its own internal algorithms. (See Lawrie paragraph 96) The app provides a mode which can be consulted by the user in order to ascertain whether the monitoring device is “live”. (See Lawrie paragraph 96) The monitoring device remains in an ‘on’ state until such a time as its power source runs out, in order to save energy, the monitoring device may provide no visible signs of the ‘on’ state. (See Lawrie paragraph 96)
The app is configured to run in the background on the smart-phone. (See Lawrie paragraph 97) This is advantageous as there is no need to actively start the app prior to driving. (See Lawrie paragraph 97) The app is configured to interrogate the monitoring device without any need for user interaction with the app. (See Lawrie paragraph 97)
The communication interface of the monitoring device may use Bluetooth, Bluetooth Smart, NFC, Wi-Fi, etc., or any suitable wireless protocol. (See Lawrie paragraph 110) The interface is configured to send an ‘advertise’ signal periodically which can be detected by a corresponding device of, for example, a driver’s smart-phone or other smart device and is configured to establish a connection with the smart-phone for the transfer of data. (See Lawrie paragraph 110) The system of the invention also provides a smartphone application which can be installed on the smart-phone for use in interrogating the monitoring device. (See Lawrie paragraph 110) The monitoring device may include one or more security components for confirming the authenticity of the device to other systems, such as a smartphone or server. (See Lawrie paragraph 202) Digital keys used by this security component(s) may include symmetric keys for short radio likes to another radio-enabled device (for instance a bluetooth link key), symmetric keys for links with multiple hops such as via a smartphone to a server, or public/private keypairs with associated algorithms to apply digital signatures to data generated by the device. (See Lawrie paragraph 202)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne in view of Fischer with disclosure of providing telematics via a monitoring app that requests confirmation of communications using a list of vehicles that are insured by an owner as taught by Lawrie in order to confirm that the correct vehicle is being monitored.
Regarding Claim 18, this claim recites substantially similar limitations as those seen in Independent Claims 2 and 12 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
A tangible, non-transitory computer-readable medium storing instructions that, when executed by a processor, causes the processor to: (See Bowne Abstract and paragraphs 8, 12, 51-54, 58, Cl. 31)
Regarding Claims 3, 13, and 20, these substantially similar claims recite the limitations of Claims 2, 12 and 18 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Bowne in view of Fischer discloses the following:
wherein: the first wireless communication address is a media access control (MAC) address corresponding to a Bluetooth device of the first vehicle, and the MAC address is determined without establishing a communication link between the mobile device and the first vehicle. (See Bowne paras 51-54, 59, 189-191, 193-194, 200 – Bluetooth MAC address for vehicle)
In addition to the rejections above as if recited herein in full, while Bowne teaches obtaining a wireless communication address and that the recognized Bluetooth connection is made by the APP when the driver and their mobile device are in the vehicle, Fischer discloses creation of a database on the driver’s personal device that associated the subject’s driven vehicle’s Bluetooth MAC address to the driver’s personal device without establishing a communication link between the mobile device and the first vehicle.
Fischer discloses his invention as to a method and system for detecting unsafe or suspect activities such as distracted driving associated with distracted driving events to the road type, vehicle speed and acceleration at the time of the distracted driving event. (See Fischer paragraph 4) The system employs a smartphone application coupled with a central server that computes driver safety scores which relate time of day, road type, vehicle speed, vehicle acceleration (positive, negative and lateral) and distracted driving using the Cauchy distribution equation. (See Fischer paragraph 4)
The disclosed method for tracking driving habits includes associating a personal device with a driver in a vehicle, determining that the driver is engaging in a suspect activity while driving, comparing the suspect activity with a severity scale indicative of a relative risk of the activity, computing a score based on the comparison and reporting the determined suspect activity and the score to a repository for accumulating a driving history of a driver. (See Fischer paragraph 8) The method may include more specific operations depending on the type of suspect event, for example, the method for tracking driving events may include determining, via a personal device associated with the driver in a vehicle, a speed of the vehicle. (See Fischer paragraph 8)
Fischer discloses that distracted driving is any activity that could divert a person’s attention away from the primary task of driving, particular interactive apps because text messaging, email usage and web browsing require visual, manual and cognitive attention from the driver, they are by far the most alarming distractions. (See Fischer paragraph 18) The method and system for detecting distracted driving associates distracted driving events to the road type, vehicle speed and vehicle acceleration (positive, negative and lateral) at the time of the distracted driving event and using the Cauchy distribution equation, provides summary and detail reports of driving scores and distracted driving events to concerned parties including insurance companies and vehicle owners. (See Fischer paragraph 19)
Fischer discloses a computing environment suitable for all of the disclosed configurations of the invention where the monitored driving environment, a driving evaluator application (app) executes on a personal electronic device such as a mobile phone or smartphone and the app gathers data and events pertaining to driving performance and is associated with a driver of a vehicle. (See Fischer paragraph 29 and Fig. 1) The personal device includes sensors and components for sensing the data indicative of the suspect activity, such as a GPS interface, accelerometer, telematics interface and ambient light sensor. (See Fischer paragraphs 32-33)
The method for tracking driving habits includes associating a personal device with a driver in a vehicle which may include associating the personal device with the vehicle by identifying a positioning device disposed in the vehicle of a monitored driver, in which the positioning device is a telematics unit (appliance) responsive to the personal device. (See Fischer paragraph 55) Applicant invocation may be facilitated by near field communication (NFC) based on proximity to the vehicle, such as the application is invoked automatically each time the driver enters the vehicle. (See Fischer paragraph 55 and FIGS. 5A-C – application is invoked based on proximity to vehicle and invoked automatically each time the driver enters the vehicle [detection by mobile device based on proximity when driver enters the vehicle)
Communications between the personal device and the telematics appliance includes at least one of Bluetooth, BLE, WiFi, NFC and transmissions under IEEE 802.11, or other suitable wired or wireless mechanism. (See Fischer paragraph 71) The personal device is a typical cellphone or smartphone carried by the user and may include any suitable phone, tablet, laptop, watch, or other computing and telecommunications device specific to the user and adapted for wireless electronic communication and execution of apps defined by preprogrammed computing instructions. (See Fischer paragraph 73 – mobile device)
In operation, the disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s VIN to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s VIN to the driver’s personal device. (See Fischer paragraph 75) An alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Bluetooth device serial number (BD_ADDR or MAC address) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Bluetooth device serial number to the driver’s personal device. (See Fischer paragraphs 75-76 – obtained MAC address without establishing a communication link to the vehicle)
A third alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Wifi device serial number (commonly called Media Access Control (MAC) address) or unique Wifi device Service Set Identifier (SSID) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Wifi Media Access Control (MAC) address to the driver’s personal device. (See Fischer paragraph 77)
Upon driver invocation of the monitoring app on their device, identification of the user device may include receiving the VIN, BD_ADDR, MAC address or SSID to ascertain if the user’s personal device is being used within the subject driven vehicle. (See Fischer paragraphs 78-79 – determining if wireless communication address corresponds to a known vehicle of insured driver, stores list of vehicles including VIN, MAC, BD_ADDR, etc. in personal device database or server database)
In operation, a scenario may be anticipated where multiple passengers, each with a personal device, is invoked. (See Fischer paragraph 79) Distracted driving can be ascertained when a personal device is invoked from a paired vehicle associated with that device, since only the regular operator would be paired. (See Fischer paragraph 79 – the pairing indicates that the known operator [insured driver] corresponds to the insured vehicle)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne with the method and system for detecting unsafe or suspect activities such as distracted driving that is associated to road type, vehicle speed and vehicle acceleration as taught by Fischer in order to use such additional data in the risk analysis of a driver to determine appropriate insurance products or premiums for a driver based on the collected data on driving behavior.
Regarding Claim 4, this claim recites the limitations of Claim 2 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne in view of Fischer and Lawrie discloses the following:
wherein the list of wireless communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, the method further comprising:
determining, by the processor, that the list of wireless communication addresses does not include the first wireless communication address;
based on determining that the list of wireless communication addresses does not include the first communication address, obtaining, by the processor, a verification that the first vehicle is covered by the insurance policy; and (See Bowne paragraphs 51-54, 59, 189-191, 193-194, 200, Figs. 10-11E - Bluetooth pairing setup is needed to complete registration or modify the vehicle which is being operated [in order to pair, the MAC address has to correspond], once the user successfully creates an account, the application always runs in the background for collection of data [verification from insured driver that the MAC address corresponds to the Bluetooth device of the vehicle])
responsive to receiving the verification, storing in the list, by the processor, the first wireless communication address. (See Bowne paragraph 193-194, 200 – if the pairing is successful, the data including the Bluetooth pairing would be in the application to allow it to connect and may be transmitted to a server)
While Bowne teaches the invention as disclosed and does teach obtaining a wireless communication address of an insured driver and that after registration the recognized Bluetooth connection is made by the APP when the driver and their mobile device are in the vehicle, Fischer more clearly discloses creation of a database on the driver’s personal device that associates the subject’s driven vehicle’s Bluetooth device MAC address to the driver’s personal device without establishing a communication link and association of a personal device with a driver in a known vehicle.
Fischer discloses his invention as to a method and system for detecting unsafe or suspect activities such as distracted driving associated with distracted driving events to the road type, vehicle speed and acceleration at the time of the distracted driving event. (See Fischer paragraph 4) The system employs a smartphone application coupled with a central server that computes driver safety scores which relate time of day, road type, vehicle speed, vehicle acceleration (positive, negative and lateral) and distracted driving using the Cauchy distribution equation. (See Fischer paragraph 4)
The disclosed method for tracking driving habits includes associating a personal device with a driver in a vehicle, determining that the driver is engaging in a suspect activity while driving, comparing the suspect activity with a severity scale indicative of a relative risk of the activity, computing a score based on the comparison and reporting the determined suspect activity and the score to a repository for accumulating a driving history of a driver. (See Fischer paragraph 8) The method may include more specific operations depending on the type of suspect event, for example, the method for tracking driving events may include determining, via a personal device associated with the driver in a vehicle, a speed of the vehicle. (See Fischer paragraph 8)
Fischer discloses that distracted driving is any activity that could divert a person’s attention away from the primary task of driving, particular interactive apps because text messaging, email usage and web browsing require visual, manual and cognitive attention from the driver, they are by far the most alarming distractions. (See Fischer paragraph 18) The method and system for detecting distracted driving associates distracted driving events to the road type, vehicle speed and vehicle acceleration (positive, negative and lateral) at the time of the distracted driving event and using the Cauchy distribution equation, provides summary and detail reports of driving scores and distracted driving events to concerned parties including insurance companies and vehicle owners. (See Fischer paragraph 19)
Fischer discloses a computing environment suitable for all of the disclosed configurations of the invention where the monitored driving environment, a driving evaluator application (app) executes on a personal electronic device such as a mobile phone or smartphone and the app gathers data and events pertaining to driving performance and is associated with a driver of a vehicle. (See Fischer paragraph 29 and Fig. 1) The personal device includes sensors and components for sensing the data indicative of the suspect activity, such as a GPS interface, accelerometer, telematics interface and ambient light sensor. (See Fischer paragraphs 32-33)
The method for tracking driving habits includes associating a personal device with a driver in a vehicle which may include associating the personal device with the vehicle by identifying a positioning device disposed in the vehicle of a monitored driver, in which the positioning device is a telematics unit (appliance) responsive to the personal device. (See Fischer paragraph 55) Applicant invocation may be facilitated by near field communication (NFC) based on proximity to the vehicle, such as the application is invoked automatically each time the driver enters the vehicle. (See Fischer paragraph 55 and FIGS. 5A-C – application is invoked based on proximity to vehicle and invoked automatically each time the driver enters the vehicle [detection by mobile device based on proximity when driver enters the vehicle)
Communications between the personal device and the telematics appliance includes at least one of Bluetooth, BLE, WiFi, NFC and transmissions under IEEE 802.11, or other suitable wired or wireless mechanism. (See Fischer paragraph 71) The personal device is a typical cellphone or smartphone carried by the user and may include any suitable phone, tablet, laptop, watch, or other computing and telecommunications device specific to the user and adapted for wireless electronic communication and execution of apps defined by preprogrammed computing instructions. (See Fischer paragraph 73 – mobile device)
In operation, the disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s VIN to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s VIN to the driver’s personal device. (See Fischer paragraph 75) An alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Bluetooth device serial number (BD_ADDR or MAC address) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Bluetooth device serial number to the driver’s personal device. (See Fischer paragraphs 75-76 – obtained MAC address without establishing a communication link to the vehicle)
Upon driver invocation of the monitoring app on their device, identification of the user device may include receiving the VIN, BD_ADDR, MAC address or SSID to ascertain if the user’s personal device is being used within the subject driven vehicle. (See Fischer paragraphs 78-79 – determining if wireless communication address corresponds to a known vehicle of insured driver)
A third alternative disclosed approach creates a database on the driver’s personal device that associates the subject driven vehicle’s unique Wifi device serial number (commonly called Media Access Control (MAC) address) or unique Wifi device Service Set Identifier (SSID) to the driver’s personal device and/or creates a database on a server that associates the subject driven vehicle’s unique Wifi Media Access Control (MAC) address to the driver’s personal device. (See Fischer paragraph 77)
Upon driver invocation of the monitoring app on their device, identification of the user device may include receiving the VIN, BD_ADDR, MAC address or SSID to ascertain if the user’s personal device is being used within the subject driven vehicle. (See Fischer paragraphs 78-79 – determining if wireless communication address corresponds to a known vehicle of insured driver, stores list of vehicles including VIN, MAC, BD_ADDR, etc. in personal device database or server database)
In operation, a scenario may be anticipated where multiple passengers, each with a personal device, is invoked. (See Fischer paragraph 79) Distracted driving can be ascertained when a personal device is invoked from a paired vehicle associated with that device, since only the regular operator would be paired. (See Fischer paragraph 79 – the pairing indicates that the known operator [insured driver] corresponds to the insured vehicle)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne with the method and system for detecting unsafe or suspect activities such as distracted driving that is associated to road type, vehicle speed and vehicle acceleration as taught by Fischer in order to use such additional data in the risk analysis of a driver to determine appropriate insurance products or premiums for a driver based on the collected data on driving behavior.
While Bowne in view of Fischer, as disclosed above do disclose that the app populates and saves information regarding vehicles covered and connects the tracking of vehicles to those noted in the app implying that there is a list of vehicles covered by an insurance policy of the insured driver and discloses pairing to the vehicle Bluetooth which would match the wireless communication addresses, Bowne in view of Fischer does not disclose a list per se of one of more vehicles covered by an insurance policy of an insured driver and matching first wireless communication address to the second wireless communication address stored in memory or determining that the list of wireless communication addresses does not include the first wireless communication address.
Lawrie discloses his invention as to a monitoring apparatus that provides vehicle telematics data where the monitoring apparatus includes a sensor for sensing vehicle and engine motion induced vibration in part of a vehicle and for generating vibration associated data where the sensor is coupled to part of the vehicle. (See Lawrie Abstract)
The monitoring device preferably uses short range wireless radio technology such as Bluetooth, and is provided with a clock. (See Lawrie paragraph 66) The communication apparatus may be arranged to operate with a wireless communication technology and may be arranged, for example, to operate with a wireless communication technology complying with Bluetooth low energy protocol. (See Lawrie paragraph 66) The invention may also provide a system including the monitoring device, a portable smart device configured for communication with the device and a remote server configured to communicate with the smart device to obtain the data. (See Lawrie paragraph 67)
Lawrie further discloses a smart user communication device comprising a smart device application (“app”) for communicating with the monitoring device and a secure remote server for handling analysis, reporting and alerting configured to communicate with the smart device 26 via the app 28 and a communication network 13 such as the internet. (See Lawrie paragraph 87 and Fig. 1) In an exemplary system, the monitoring device is configured to monitor vehicle usage data and to wireless transmit this data to the app installed on the smart user communication device, here a smartphone that is configured to transmit the received vehicle usage data via the app over the internet to the secure remote server. (See Lawrie paragraph 87) The monitoring device is arranged to use short range radio technology such as Bluetooth. (See Lawrie paragraph 89)
The secure remote server may belong to an insurance company and would allow the insurance company to track the driving behavior of a driver and establish a risk profile based on the driving behavior for that driver, for insurance purposes. (See Lawrie paragraph 88)
Typically, the smart phone can operate with a wireless communication technology of Bluetooth, BLE or Bluetooth Smart protocol and can typically make use of GPS. (See Lawrie paragraph 90)
The app will typically be installed by the user on the smart-phone. (See Lawrie paragraph 91) The app comprises a ‘scan’ mode in which it causes the smart-phone to scan for nearby monitoring devices and to provide a list of permissible devices seen by the user. (See Lawrie paragraph 92 – scan for nearby devices and provides a permissible list of devices seen by the user) The user can then select the appropriate monitoring device from the list using the app and assign the correct monitoring device to the correct vehicle. (See Lawrie paragraph 92) The device is able to reject communication requests from an unassociated app from another user. (See Lawrie paragraph 92)
Beneficially, the monitoring device also has a mode for providing an indication to the user to confirm that the app is indeed communicating with the monitoring device that the user believes it to be. (See Lawrie paragraph 93) This is particular useful for situations where a new or previously un-paired monitoring device is to be utilized, especially when there are a number of potential choices in the vicinity (e.g., multi-card insurance, where the owner is pairing all of their vehicle/tags at once.) (See Lawrie paragraph 93 – list of insured vehicles; un-paired monitoring device [first wireless communication address not included if the vehicle is new or previously unpaired])
Once the app and the monitoring device are communicating the app requests that the user confirms that the monitoring device is attached to the vehicle that is associated with the user in the app or requests that the user identify the vehicle to which the monitoring device is attached either by selecting from a list of vehicles provided on a selection page in the app (if multiple vehicles are associated with the user in the app) or manually if the app does not currently have the details of the vehicle. (See Lawrie paragraph 95 – list of vehicles associated with the user in the app, matches the communication between the app and the monitoring device)
Once the app has completed linking the monitoring device to the correct vehicle, no further user setup is required and the monitoring device is able to auto-configure its own internal algorithms. (See Lawrie paragraph 96) The app provides a mode which can be consulted by the user in order to ascertain whether the monitoring device is “live”. (See Lawrie paragraph 96) The monitoring device remains in an ‘on’ state until such a time as its power source runs out, in order to save energy, the monitoring device may provide no visible signs of the ‘on’ state. (See Lawrie paragraph 96)
The app is configured to run in the background on the smart-phone. (See Lawrie paragraph 97) This is advantageous as there is no need to actively start the app prior to driving. (See Lawrie paragraph 97) The app is configured to interrogate the monitoring device without any need for user interaction with the app. (See Lawrie paragraph 97)
The communication interface of the monitoring device may use Bluetooth, Bluetooth Smart, NFC, Wi-Fi, etc., or any suitable wireless protocol. (See Lawrie paragraph 110) The interface is configured to send an ‘advertise’ signal periodically which can be detected by a corresponding device of, for example, a driver’s smart-phone or other smart device and is configured to establish a connection with the smart-phone for the transfer of data. (See Lawrie paragraph 110) The system of the invention also provides a smartphone application which can be installed on the smart-phone for use in interrogating the monitoring device. (See Lawrie paragraph 110) The monitoring device may include one or more security components for confirming the authenticity of the device to other systems, such as a smartphone or server. (See Lawrie paragraph 202) Digital keys used by this security component(s) may include symmetric keys for short radio likes to another radio-enabled device (for instance a bluetooth link key), symmetric keys for links with multiple hops such as via a smartphone to a server, or public/private keypairs with associated algorithms to apply digital signatures to data generated by the device. (See Lawrie paragraph 202)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne in view of Fischer with disclosure of providing telematics via a monitoring app that requests confirmation of communications using a list of vehicles that are insured by an owner as taught by Lawrie in order to confirm that the correct vehicle is being monitored.
Regarding Claim 5, this claim recites the limitations of Claim 2 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
identifying, by the processor and based on a first portion of the telematics data, a movement of the first vehicle indicative of a beginning of a vehicle trip; and (See Bowne paragraphs 42-44, 46-47, 61, 203-205 – automatic start and stop capabilities are accomplished with smartphone sensors)
identifying, by the processor and based on a second portion of the telematics data, a state of the first vehicle indicative of an end of the vehicle trip. (See Bowne paragraphs 42-44, 46-47, 61, 203-205 – automatic start and stop capabilities are accomplished with smartphone sensors)
Regarding Claim 6, this claim recites the limitations of Claim 5 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
wherein the state of the vehicle indicative of an end of the vehicle trip is identified based on the second portion of the telematics data indicating: (See Bowne paragraphs 40-44, 59-61, 64, 66-68, 78, 80-84, 107-109, 197-200, 203-205, 213-215, Cl. 4-5)
a speed of zero for longer than a first threshold period of time, a deceleration immediately followed by a lack of acceleration for longer than a second threshold period of time, or no change in position for longer than a third threshold period of time. (See Bowne paragraphs 59-61, 64, 66-68, 78, 80-84, 197-200, 203-205, 213-215 – triggering events, detecting when engine is turned off [no change in position]; information about the vehicle not moving (i.e., idling or at 0 mph) is collected, data from acceleration, stops, etc. is collected until vehicle is turned off [end of trip])
Regarding Claim 7, this claim recites the limitations of Claim 5 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
wherein the mobile application is switched from the background state to the active state based on identifying the movement indicative of the beginning of the vehicle trip. (See Bowne paragraphs 42-44, 46-47, 61, 203-205 – automatic start and stop capabilities are accomplished with smartphone sensors)
Regarding Claim 8, this claim recites the limitations of Claim 5 and as to those limitations is rejected for the same basis and reasons as disclosed above.
wherein the mobile application collects the telematics data in a memory associated with the mobile device, the method further comprising: (See Bowne paras 46, 51-55, 58-60, Fig. 2-3)
based on identifying the end of the vehicle trip; See Bowne paragraphs 42-44, 46-47, 61, 203-205 – automatic start and stop capabilities are accomplished with smartphone sensors)
transmitting, by the processor, from the memory to a remote server, the telematics data; and (See Bowne paragraphs 51, 87, 190-191, 203, 212-215, Fig. 5)
switching, by the processor, the mobile application from the active state to the background state. (See Bowne paragraphs 40-44, 59-61, 65, 107-109, 203-205, 212-215, Cl. 4-5)
Regarding Claim 9, this claim recites the limitations of Claim 2 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
updating, by the processor and based on the driving behavior exhibited by the first vehicle, a cost associated with the insurance policy. (See Bowne paragraphs 2, 8-11, 50-54, 178, 206-210)
garding Claim 10, this claim recites the limitations of Claim 9 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
accessing, by the processor and from a remote server, a driving history associated with the insurance policy; and (See Bowne paragraphs 87, 113-116, 178, 190-191, 196-199, 203)
displaying, by the processor and on a display associated with the first vehicle, the driving behavior and the driving history. (See Bowne paragraphs 49-50, 86, 183-186, 196-199, 201, 203)
Regarding Claim 11, this claim recites the limitations of Claim 2 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne in view of Fischer additionally disclose:
wherein the sensor includes at least one of a proximity sensor, an ambient light sensor, or a barometer, and the telematics data includes a set of values indicative of each one of speeding, braking, cornering, or mobile device usage. (See Bowne paras 47, 51-55 – sensors may include proximity sensors, barometer and ambient light; paras 47-48, 70-71, 79-80, 191, 196-198 – telematics data includes acceleration, braking, cornering, speed)
While Bowne teaches the invention as disclosed and does teach obtaining a wireless communication address of an insured driver and that after registration the recognized Bluetooth connection is made by the APP when the driver and their mobile device are in the vehicle, Fischer more clearly discloses creation of a database on the driver’s personal device that associates the subject’s driven vehicle’s Bluetooth device MAC address to the driver’s personal device and association of a personal device with a driver in a known vehicle. Further, while Bowne discloses collection of a plurality of vehicle telematics data, it does not disclose collection of mobile device usage data. Fischer further discloses additional types of collected telematics data including data regarding mobile device usage and speed.
Fischer discloses his invention as to a method and system for detecting unsafe or suspect activities such as distracted driving associated with distracted driving events to the road type, vehicle speed and acceleration at the time of the distracted driving event. (See Fischer paragraph 4) The system employs a smartphone application coupled with a central server that computes driver safety scores which relate time of day, road type, vehicle speed, vehicle acceleration (positive, negative and lateral) and distracted driving using the Cauchy distribution equation. (See Fischer paragraph 4)
The disclosed method for tracking driving habits includes associating a personal device with a driver in a vehicle, determining that the driver is engaging in a suspect activity while driving, comparing the suspect activity with a severity scale indicative of a relative risk of the activity, computing a score based on the comparison and reporting the determined suspect activity and the score to a repository for accumulating a driving history of a driver. (See Fischer paragraph 8) The method may include more specific operations depending on the type of suspect event, for example, the method for tracking driving events may include determining, via a personal device associated with the driver in a vehicle, a speed of the vehicle. (See Fischer paragraph 8)
Fischer discloses that distracted driving is any activity that could divert a person’s attention away from the primary task of driving, particular interactive apps because text messaging, email usage and web browsing require visual, manual and cognitive attention from the driver, they are by far the most alarming distractions. (See Fischer paragraph 18 – mobile device usage) The method and system for detecting distracted driving associates distracted driving events to the road type, vehicle speed and vehicle acceleration (positive, negative and lateral) at the time of the distracted driving event and using the Cauchy distribution equation, provides summary and detail reports of driving scores and distracted driving events to concerned parties including insurance companies and vehicle owners. (See Fischer paragraph 19)
Fischer discloses a computing environment suitable for all of the disclosed configurations of the invention where the monitored driving environment, a driving evaluator application (app) executes on a personal electronic device such as a mobile phone or smartphone and the app gathers data and events pertaining to driving performance and is associated with a driver of a vehicle. (See Fischer paragraph 29 and Fig. 1) The personal device includes sensors and components for sensing the data indicative of the suspect activity, such as a GPS interface, accelerometer, telematics interface and ambient light sensor. (See Fischer paragraphs 32-33)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system for determining a vehicle insurance premium for a period of time based at least in part on collected vehicle operation data as disclosed by Bowne with the method and system for detecting unsafe or suspect activities such as distracted driving that is associated to road type, vehicle speed and vehicle acceleration as taught by Fischer in order to use such additional data in the risk analysis of a driver to determine appropriate insurance products or premiums for a driver based on the collected data on driving behavior.
Regarding Claim 14, this claim recites the limitations of Claim 12 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
identify, based on a first portion of the telematics data, a movement of the first vehicle indicative of a beginning of a vehicle trip, wherein the mobile application is switched from the background state to the active state further based on identifying the movement indicative of the beginning of the vehicle trip. (See Bowne paragraphs 40-44, 59-61, 191-195, 203-205 - the software application (“APP”), once downloaded to the smartphone, may collect data using the smartphone’s sensors to automatically start and stop the APP once initially set up on the smartphone. The smartphone may communicate with the vehicle via Bluetooth to determine that the smartphone is inside the vehicle and the engine is running [background state] and once detected, the APP may then turn itself on [activated state] and begin tracking miles driven, location, time and vehicle dynamics [first movement indicating beginning of a vehicle trip]
Regarding Claim 15, this claim recites the limitations of Claim 12 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
wherein the mobile application collects the telematics data in a memory associated with the mobile device. (See Bowne paras 46, 51-55, 58-60, Fig. 2-3)
Regarding Claim 16, this claim recites the limitations of Claim 12 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
Identify, based on the telematics data, a stopped state of the first vehicle indicating: (See Bowne paragraphs 40-44, 59-61, 64, 66-68, 78, 80-84, 107-109, 197-200, 203-205, 213-215, Cl. 4-5 – end of trip indicates a stopped state)
a speed of zero for longer than a first threshold period of time, a deceleration immediately followed by a lack of acceleration for longer than a second threshold period of time, or no change in position for longer than a third threshold period of time; and (See Bowne paragraphs 59-61, 64, 66-68, 78, 80-84, 197-200, 203-205, 213-215 – triggering events, detecting when engine is turned off [no change in position]; information about the vehicle not moving (i.e., idling or at 0 mph) is collected, data from acceleration, stops, etc. is collected until vehicle is turned off [end of trip])
based, on identifying the stopped state, switch the mobile application from the active state to the background state. (See Bowne paragraphs 40-44, 59-61, 65, 107-109, 203-205, 212-215, Cl. 4-5)
Regarding Claim 17, this claim recites the limitations of Claim 12 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
wherein the list of wireless communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, and the instructions, when executed by the processor, further cause the processor to:
update, based on the driving behavior, an aspect of the insurance policy, the aspect of the insurance policy including at least one of: a premium, a deductible, a discount, or a coverage level. (See Bowne paragraphs 2, 8-11, 50-54, 178, 206-210)
Regarding Claim 19, this claim recites the limitations of Claim 18 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
identify, based on a first portion of the telematics data, a movement of the first vehicle indicative of a beginning of a vehicle trip, wherein the mobile application is switched from the background state to the active state further based on identifying the movement indicative of the beginning of the vehicle trip; (See Bowne paragraphs 40-44, 59-61, 191-195, 203-205 - the software application (“APP”), once downloaded to the smartphone, may collect data using the smartphone’s sensors to automatically start and stop the APP once initially set up on the smartphone. The smartphone may communicate with the vehicle via Bluetooth to determine that the smartphone is inside the vehicle and the engine is running [background state] and once detected, the APP may then turn itself on [activated state] and begin tracking miles driven, location, time and vehicle dynamics [first movement indicating beginning of a vehicle trip]
identify, based on a second portion of the telematics data, a stopped state of the first vehicle indicative of an end of the vehicle trip; and (See Bowne paragraphs 40-44, 59-61, 64, 66-68, 78, 80-84, 107-109, 197-200, 203-205, 213-215, Cl. 4-5 – end of the trip indicates a stopped state)
based on identifying the stopped state, switch the mobile application from the active state to the background state. (See Bowne paragraphs 40-44, 59-61, 65, 107-109, 203-205, 212-215, Cl. 4-5)
Regarding Claim 21, this claim recites the limitations of Claim 18 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Bowne discloses the following:
wherein the list of wireless communication addresses identifies vehicles covered by an insurance policy associated with the first vehicle, and the instructions further causing the processor to:
access, from a remote server, a driving history associated with the insurance policy; (See Bowne paragraphs 87, 113-116, 178, 190-191, 196-199, 203) and
display, on a display associated with the first vehicle, the driving behavior and the driving history. (See Bowne paragraphs 49-50, 86, 183-186, 196-199, 201, 203)
Additional Relevant Prior Art Not Currently Being Applied
Hassib et al. (US PG Pub. 2013/0289819) – disclosing systems and method for telematics monitoring that includes at least a portion of one or more of ID data, sensor data and/or operational count data.
Grokop et al. (US PG Pub. 2015/0120336) – disclosing collecting and transmitting telematics data from a user’s mobile device, to one or more automobile insurers. The telematics data contains information that may be correlated with the risk of claim/accident. From this and other data, the insurer may compute either a policy premium for the user, or a policy discount (e.g., expressed as a percentage)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMBREEN A. ALLADIN whose telephone number is (571)270-3533. The examiner can normally be reached Monday - Friday 9-5.
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, Abhishek Vyas can be reached at 571-270-1836. 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.
/AMBREEN A. ALLADIN/Primary Examiner, Art Unit 3691 February 1, 2026