US20150109099A1 - Mobile device and key fob pairing for multi-factor security - Google Patents

Abstract

Systems and methods may provide for determining a first proximity status of a first mobile device with respect to a vehicle, and determining a second proximity status of a second mobile device with respect to the vehicle. Additionally, an accessibility of one or more functions of the vehicle may be configured based at least in part on the first proximity status and the second proximity status. In one example, a policy associated with one or more of the first mobile device and the second mobile device may be identified, wherein the accessibility is configured further based on the policy.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• The present application is a continuation of U.S. patent application Ser. No. 13/631,440 filed Sep. 28, 2012, issued as U.S. Pat. No. 8,933,778.
BACKGROUND
• Embodiments generally relate to security systems. More particularly, embodiments relate to the use of multiple factors to control access to vehicles.
• Vehicle entry systems may include proximity-based keyless remotes (e.g., key fobs) that may be used to access and/or start the vehicle. While these solutions may be suitable under certain circumstances, there remains considerable room for improvement. For example, unauthorized access and/or operation of the vehicle may be achieved by simply gaining possession of the key fob, which may be the sole user authentication factor with respect to the vehicle. Moreover, if the key fob is lost or stolen, a new key fob may need to be ordered, which may be of considerable cost, delay and inconvenience to the owner. Although certain smart phone applications may allow remote control of vehicles, these applications may also be limited to the use of login credentials to establish the phone as the only user authentication factor with respect to the vehicle, wherein the login credentials may be easily compromised. Moreover, smart phone-based solutions may involve the use of an intermediary (e.g., service provider) between the phone and the vehicle.
BRIEF DESCRIPTION OF THE DRAWINGS
• The various advantages of the embodiments of the present invention will become apparent to one skilled in the art by reading the following specification and appended claims, and by referencing the following drawings, in which:
• FIG. 1 is a block diagram of an example of an authentication environment according to an embodiment;
• FIGS. 2A and 2B are block diagrams of examples of factor replacement scenarios according to embodiments;
• FIG. 3 is a block diagram of an example of a logic architecture according to an embodiment;
• FIG. 4 is a block diagram of an example of a set of user profiles according to an embodiment;
• FIG. 5 is a flowchart of an example of a method of managing a multi-factor authentication environment according to an embodiment;
• FIG. 6 is a block diagram of an example of a processor according to an embodiment; and
• FIG. 7 is a block diagram of an example of a system according to an embodiment.
DETAILED DESCRIPTION
• Turning now toFIG. 1, anauthentication environment10 is shown in which access to and control over avehicle14 is managed relative to a plurality ofmobile devices16,18 that are paired with thevehicle14. In the illustrated example, a firstmobile device16 is a key fob (e.g., wireless hardware security token) and a secondmobile device18 is a smart phone. Themobile devices16,18 may also include other types of devices such as smart tablets, personal digital assistants (PDAs), media players, imaging devices, and so forth, wherein auser12 may carry themobile devices16,18 with him or her as the user approaches and interacts with thevehicle14. As will be discussed in greater detail, the presence of themobile devices16,18 may be required in order to authenticate theuser12, wherein successful authentication may result in certain functions of thevehicle14 being made available to theuser12. For example, the presence of bothmobile devices16,18 may be required before theuser12 is permitted to access the vehicle14 (e.g., door and/or trunk unlock function), start the vehicle14 (e.g., ignition function), customize various settings (e.g., user setting function), drive the vehicle14 (e.g., vehicle operation function), pair devices with the vehicle14 (e.g., device pairing function), and so forth. Accordingly, the illustratedenvironment10 represents a “multi-factor” authentication environment in which the security of thevehicle14 is a function of the proximity status of multiplemobile devices16,18.
• As will also be discussed in greater detail, user policies and/or profiles may also be used to make certain functions, such as vehicle access and device pairing, available to theuser12 even if only one of themobile devices16,18 is present. Additionally, although two mobile devices are shown, more than two mobile devices may also be used by a given user to access vehicle functions. For example, theuser12 may pair a smart phone, smart tablet and media player with thevehicle14, and designate the smart phone as the primary (e.g., “master”) device, wherein the primary device may be used to pair other devices with thevehicle14.
• For example,FIG. 2A demonstrates that a policy may be implemented in which theuser12 is permitted to enter thevehicle14 if the firstmobile device16 is present but the secondmobile device18 is not present. Such a case might occur if the secondmobile device18 becomes lost or stolen, or theuser12 merely forgets to bring the secondmobile device18. The policy, which may be implemented as a user profile corresponding to theuser12 or as a global policy (e.g., default profile) applicable to all users or groups of users, may also permit a replacement device20 (e.g., smart phone) to be paired with thevehicle14, provided that theuser12 successfully satisfies a login constraint (e.g., inputs a predefined passcode) associated with the user profile of theuser12 and completes a pairing process.
• Similarly,FIG. 2B demonstrates that the user profile may permit theuser12 to enter thevehicle14 if the secondmobile device18 is present but the firstmobile device16 is not present. Such a case might occur if the firstmobile device16 becomes lost or stolen, or theuser12 merely forgets to bring the firstmobile device16. The user profile may also permit a replacement device22 (e.g., key fob) to be paired with thevehicle14, provided that theuser12 successfully satisfies the login constraint associated with the user profile of theuser12 and completes the pairing process. Accordingly, the use of a multi-factor authentication scheme may enable new factors to be paired with thevehicle14 at considerably less cost, delay and inconvenience to theuser12, while maintaining a relatively high level of security with respect to thevehicle14.
• Turning now toFIG. 3, a logic architecture24 (24a-24d) is shown, wherein thelogic architecture24 may be generally incorporated into a vehicle such as, for example, the vehicle14 (FIGS. 1,2A and2B) as hardware, software, firmware, or any combination thereof. In the illustrated example, afirst factor module24auses a proximity sensor (not shown) to determine a first proximity status of the firstmobile device16 with respect to the vehicle. Similarly, asecond factor module24bmay user a proximity sensor to determine a second proximity status of the secondmobile device18 with respect to the vehicle. Asecurity module24cmay have arequest component40 that receives a user request via a user interface (UI)30 (e.g., pushbutton, switch, etc.) of the firstmobile device16, a UI32 (e.g., touch screen, microphone, etc.) of the secondmobile device32, a UI34 (e.g., door handle, pushbutton, touch screen, etc.) of the vehicle, etc., and configure an accessibility of one or more functions26 (26a-26c) of the vehicle in response to the user request based at least in part on the first proximity status and the second proximity status. In one example, thesecurity module24cidentifies a policy such as one ormore user profiles28, wherein at least one of theuser profiles28 may be associated with the firstmobile device16 and/or the second mobile device18 (and a user corresponding to such device(s)). In such a case, thevehicle functions26 may be configured further based on the identified user profile.
• For example, thesecurity module24cmight have adenial component36 that denies user requests if the first proximity status and the second proximity status do not satisfy a multi-factor condition of the user profile. More particularly, the multi-factor condition may stipulate that bothmobile devices16,18 (e.g., factors) be present in order for the vehicle function in question to be available to the user. In such a case, if the first proximity status indicates that the firstmobile device16 is present but the second proximity status indicates that the secondmobile device18 is not present, the multi-factor condition would not be satisfied. Similarly, if the second proximity status indicates that the secondmobile device18 is present but the first proximity status indicates that the firstmobile device16 is not present, the multi-factor condition would also not be satisfied.
• Other conditions, such as time-based or location-based conditions may also be used. For example, if the user profile stipulates that the user in question (or all users if a global policy and/or default profile is implemented) is to operate the vehicle within a certain radius of a particular location (e.g., street address) and it is determined that the vehicle is outside that radius, thedenial component36 may deny operation of the vehicle (e.g., prevent ignition of the vehicle, shutdown the vehicle after providing a warning to the driver, etc.). By way of another example, if the user profile stipulates that the user in question is to operate the vehicle within a certain time period and it is determined that the current time is outside the specified time period, thedenial component36 may also deny operation of the vehicle. In addition, enforcement of the multi-factor conditions may be conducted on an ongoing basis. For example, if it is determined that, after a given user request has been granted, a condition leading to the grant of the request is no longer satisfied, the grant of the condition may be effectively reversed. Thus, shutdown of the vehicle may be implemented in such a scenario as well. Other examples may include the prohibition of radio usage while the vehicle is being operated to prevent distracted driver scenarios.
• Thesecurity module24cmay also have agrant component38 that grants user requests if the first proximity status and the second proximity status satisfy the multi-factor condition of the user profile. As will be discussed in greater detail, thegrant component38 may also apply one or more constraints such as, for example, a time constraint, location constraint, login constraint, etc., of the user profile to the vehicle function in question. With specific regard to the login constraint, the illustratedarchitecture24 also includes apairing module24dconfigured to pair the first and secondmobile devices16,18, as well as replacement devices such as device20 (FIG. 2A) and device22 (FIG. 2B), with the vehicle. Themobile devices16,18, and replacement devices20 (FIG. 2A),22 (FIG. 2B) may also be paired with one another. If both factors are present, thepairing module24dmay manage the pairing process normally. If, on the other hand, only one of the factors is present, thepairing module24dmay permit entry to the vehicle and then prompt the user to enter a passcode (e.g., personal identification number/PIN, password, etc.) before proceeding with the pairing process.
• With further regard to thepairing module24d,the passcode may be entered on one of themobile devices16,18, or in some embodiments may be required to be entered directly into thevehicle UI34 in order to pair thedevices16,18. In another embodiment, automatic pairing may be enabled, wherein a default policy and/or user profile may be used until a “master” (e.g., primary) device is defined. For example, one device may be considered to be a master that is to be present in order to pair other devices together and with the vehicle (one master key fob, for instance). In some embodiments, pairing may only be completed when the master device is also present (e.g., in order to pair a lesser privileged smart phone, for instance, operated by a child, minor, or other non-owner of the vehicle and a smart phone). In some embodiments, a second device (e.g., smart phone rather than key fob) may be identified as a master device at the time of pairing to enable entry of user constraints on other secondary devices. These other secondary “non-master” devices (e.g., lesser privileged smart phone) may be prevented from changing their own user constraints. Secondary devices may receive user constraints to be stored on the device via a number of means: Bluetooth, wireless, NFC (near field communication), synching to computer or other docking station, etc. The user constraints may then be non-modifiable, however except in the presence of the master device.
• Additionally, the illustratedsecurity module24chas anotification component42 configured to generate a notification via theUI30 of the firstmobile device16, theUI32 of the secondmobile device18, and/or theUI34 of the vehicle if either the first proximity status indicates that the first mobile device is not present or the second proximity status indicates that the second mobile device is not present. More particularly, such a notification may be useful in cases where a bona fide user is attempting to operate the vehicle without one of the factors (e.g., forgotten factor is missing) as well as cases where an unauthorized user is attempting to operate the vehicle without one of the factors (e.g., stolen factor is present). The notification may be sent to the nearby factor (e.g., in the case of a forgotten factor) and/or the missing factor (e.g., in the case of a stolen factor), depending upon the circumstances.
• In the illustrated example, each of themobile devices16,18, includes apolicy repository17 to store a policy that has one or more multi-factor conditions, as well as awireless interface19 to receive a request from thesecurity module24cof the vehicle and transmit the policy to thesecurity module24cin response to the request. In one example, the policy is a user profile. As already noted, a given multi-factor condition may indicate whether thefunctions26 of the vehicle are to be accessible if either the firstmobile device16 or the secondmobile device18 are not in proximity of the vehicle during an attempted access of thefunctions26 of the vehicle. The policy may be transmitted to thesecurity module24cin conjunction with a pairing process and/or an attempt to access one or more of thefunctions26 of the vehicle.
• With further regard to the pairing process, the illustratedmobile devices16,18 also include apairing module21 that is configured to pair the respective device with the vehicle and/or other devices. In one example, thepairing module21 of the firstmobile device16 receives a passcode via theUI30 and determines whether the passcode satisfies a login constraint of the policy, wherein the firstmobile device16 is paired if the passcode satisfies the login constraint. Similarly, thepairing module21 of the secondmobile device18 may receive a passcode via theUI32 and determine whether the passcode satisfies the login constraint of the policy, wherein the secondmobile device18 is paired if the passcode satisfies the login constraint. Alternatively, the determination as to whether the passcode satisfies the login constraint may be conducted by the vehicle. Moreover, in some instances, a mobile device such as, for example, the first mobile device16 (e.g., key fob) may not have the capability to support the entry of login credentials. In such a case, theUI34 of the vehicle may be used, or the login process may be bypassed altogether if the device is a master device.
• FIG. 4 shows a set ofuser profiles28 structured as a table. In the illustrated example, a plurality of users (e.g., “Dad”, “Mom”, “Sally”) each has various preferences that are programmable/configurable. For example, a passcode, the number of factors required to access the vehicle (“Access Factors”), the number of factors required to activate the vehicle ignition (“Start Factors”), the number of factors required to operate the vehicle (“Drive Factors”), location constraints, time constraints, and so forth, may all be defined on a user-by-user basis. Moreover, the specified parameters may be used to determine whether to grant user requests, as well as to apply user-specific conditions to granted requests. Of particular note is that different users may have different policies. For example, Mom and Dad are able to start the vehicle with only one factor present, whereas Sally's profile calls for two factors to be present in order to start the vehicle, in the illustrated example. Although the illustrated set of user profiles28 is structured as a table, the set ofuser profiles28 may also utilize other known structures such as relational database structures and/or linked lists to track, manage, control and organize the data represented therein.
• Turning now toFIG. 5, amethod44 of managing a multi-factor authentication environment is shown. Themethod44 may be implemented as a set of logic instructions and/or firmware stored in a machine- or computer-readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), flash memory, etc., in configurable logic such as, for example, programmable logic arrays (PLAs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), in fixed-functionality logic hardware using circuit technology such as, for example, application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof. For example, computer program code to carry out operations shown in themethod44 may be written in any combination of one or more programming languages, including an object oriented programming language such as C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. Moreover, themethod44 may be implemented as the logic architecture24 (FIG. 3) using any of the aforementioned circuit technologies.
• Illustratedprocessing block46 provides for receiving a user request via a user interface of, for example, a first mobile device, a second mobile device, a vehicle, and so forth. The user request may correspond to one or more functions of the vehicle such as a door unlock function (e.g., access request), an ignition function (e.g., start request), a user setting function (e.g., seat preferences, radio preferences), a vehicle operation function (e.g., placing/maintaining the transmission in drive), a pairing function (e.g., replacement device), and so forth. A determination may be made atblock48 as to whether a multi-factor condition is satisfied. As already noted, the multi-factor condition may take into consideration a first proximity status of a first mobile device with respect to the vehicle, a second proximity status of a second mobile device with respect to the vehicle, etc., wherein the multi-factor condition may specify whether both mobile devices are to be present in order to make the vehicle function in question available to the user. If the multi-factor condition is not satisfied, block52 may deny the user request.Block52 may also provide for generating a notification via user interface of, for example, the first mobile device, the second mobile device, the vehicle, or any combination thereof, in order to inform the vehicle owner of a missing, lost and/or stolen mobile device, as already discussed.
• If, on the other hand, the multi-factor condition is satisfied, illustratedblock50 grants the user request and applies any relevant constraints to the request. Both the multi-factor condition and the constraints may be defined on a user-by-user basis and stored in an appropriate profile, policy, etc. In one example, the constraint is a location constraint in which the vehicle function is only available in certain locations. In another example, the constraint is a time constraint in which the vehicle function is only available at certain times and/or for certain durations of time. In yet another example, the constraint is a login constraint in which the vehicle function is only available if the user inputs a predetermined passcode. The login constraint may be particularly useful for pairing devices and replacement devices.
• FIG. 6 illustrates aprocessor core200 according to one embodiment. Theprocessor core200 may be the core for any type of processor, such as a micro-processor, an embedded processor, a digital signal processor (DSP), a network processor, or other device to execute code. Although only oneprocessor core200 is illustrated inFIG. 6, a processing element may alternatively include more than one of theprocessor core200 illustrated inFIG. 6. Theprocessor core200 may be a single-threaded core or, for at least one embodiment, theprocessor core200 may be multithreaded in that it may include more than one hardware thread context (or “logical processor”) per core.
• FIG. 6 also illustrates amemory270 coupled to theprocessor200. Thememory270 may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. Thememory270 may include one ormore code213 instruction(s) to be executed by theprocessor200 core, wherein thecode213 may implement the logic architecture24 (FIG. 3), already discussed. Theprocessor core200 follows a program sequence of instructions indicated by thecode213. Thus, theprocessor core200 may be part of a vehicle such as the vehicle14 (FIG. 1). Theprocessor core200 may also be used in a mobile device such as themobile devices16,18 (FIG. 3) to support the functionality of those devices. Each instruction may enter afront end portion210 and be processed by one ormore decoders220. Thedecoder220 may generate as its output a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals which reflect the original code instruction. The illustratedfront end210 also includesregister renaming logic225 andscheduling logic230, which generally allocate resources and queue the operation corresponding to the convert instruction for execution.
• Theprocessor200 is shown includingexecution logic250 having a set of execution units255-1 through255-N. Some embodiments may include a number of execution units dedicated to specific functions or sets of functions. Other embodiments may include only one execution unit or one execution unit that can perform a particular function. The illustratedexecution logic250 performs the operations specified by code instructions.
• After completion of execution of the operations specified by the code instructions,back end logic260 retires the instructions of thecode213. In one embodiment, theprocessor200 allows out of order execution but requires in order retirement of instructions.Retirement logic265 may take a variety of forms as known to those of skill in the art (e.g., re-order buffers or the like). In this manner, theprocessor core200 is transformed during execution of thecode213, at least in terms of the output generated by the decoder, the hardware registers and tables utilized by theregister renaming logic225, and any registers (not shown) modified by theexecution logic250.
• Although not illustrated inFIG. 6, a processing element may include other elements on chip with theprocessor core200. For example, a processing element may include memory control logic along with theprocessor core200. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches.
• Referring now toFIG. 7, shown is a block diagram of asystem1000 in accordance with an embodiment of the present invention. In one example, thesystem1000 is part of a vehicle such as thevehicle14, already discussed. Thesystem1000 may also be used in a mobile device such as themobile devices16,18 (FIG. 3) to support the functionality of those devices. Shown inFIG. 7 is amultiprocessor system1000 that includes afirst processing element1070 and asecond processing element1080. While twoprocessing elements1070 and1080 are shown, it is to be understood that an embodiment ofsystem1000 may also include only one such processing element.
• System1000 is illustrated as a point-to-point interconnect system, wherein thefirst processing element1070 andsecond processing element1080 are coupled via a point-to-point interconnect1050. It should be understood that any or all of the interconnects illustrated inFIG. 7 may be implemented as a multi-drop bus rather than point-to-point interconnect.
• As shown inFIG. 7, each ofprocessing elements1070 and1080 may be multicore processors, including first and second processor cores (i.e.,processor cores1074aand1074bandprocessor cores1084aand1084b).Such cores1074,1074b,1084a,1084bmay be configured to execute instruction code in a manner similar to that discussed above in connection withFIG. 6.
• Eachprocessing element1070,1080 may include at least one shared cache1896. The sharedcache1896a,1896bmay store data (e.g., instructions) that are utilized by one or more components of the processor, such as thecores1074a,1074band1084a,1084b,respectively. For example, the shared cache may locally cache data stored in amemory1032,1034 (e.g., computer readable medium, computer readable storage medium, etc.) for faster access by components of the processor. In one or more embodiments, the shared cache may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof.
• While shown with only twoprocessing elements1070,1080, it is to be understood that the scope of the present invention is not so limited. In other embodiments, one or more additional processing elements may be present in a given processor. Alternatively, one or more ofprocessing elements1070,1080 may be an element other than a processor, such as an accelerator or a field programmable gate array. For example, additional processing element(s) may include additional processors(s) that are the same as afirst processor1070, additional processor(s) that are heterogeneous or asymmetric to processor afirst processor1070, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processing element. There can be a variety of differences between theprocessing elements1070,1080 in terms of a spectrum of metrics of merit including architectural, microarchitectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetry and heterogeneity amongst theprocessing elements1070,1080. For at least one embodiment, thevarious processing elements1070,1080 may reside in the same die package.
• First processing element1070 may further include memory controller logic (MC)1072 and point-to-point (P-P) interfaces1076 and1078. Similarly,second processing element1080 may include aMC1082 and P-P interfaces1086 and1088. As shown inFIG. 7, MC's1072 and1082 couple the processors to respective memories, namely amemory1032 and amemory1034, which may be portions of main memory locally attached to the respective processors. While theMC logic1072 and1082 is illustrated as integrated into theprocessing elements1070,1080, for alternative embodiments the MC logic may be discrete logic outside theprocessing elements1070,1080 rather than integrated therein.
• Thefirst processing element1070 and thesecond processing element1080 may be coupled to an I/O subsystem1090 viaP-P interconnects1076,1086 and1084, respectively. As shown inFIG. 7, the I/O subsystem1090 includesP-P interfaces1094 and1098. Furthermore, I/O subsystem1090 includes aninterface1092 to couple I/O subsystem1090 with a highperformance graphics engine1038. In one embodiment, bus1049 may be used to couplegraphics engine1038 to I/O subsystem1090. Alternately, a point-to-point interconnect1039 may couple these components.
• In turn, I/O subsystem1090 may be coupled to afirst bus1016 via aninterface1096. In one embodiment, thefirst bus1016 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the present invention is not so limited.
• As shown inFIG. 7, various I/O devices1014 may be coupled to thefirst bus1016, along with abus bridge1018 which may couple thefirst bus1016 to asecond bus1020. The I/O devices1014 may include, for example, one or more proximity sensors that may be used to determine the proximity status of mobile devices with respect to a vehicle. For example, the proximity sensors may incorporate near field communications (NFC) technology, radio frequency identifier (RFID) technology, infrared (IR) technology, and so forth. In one embodiment, thesecond bus1020 may be a low pin count (LPC) bus. Various devices may be coupled to thesecond bus1020 including, for example, a keyboard/mouse1012, communication device(s)1026 (which may in turn be in communication with a computer network, not shown), and adata storage unit1018 such as a disk drive or other mass storage device which may includecode1030, in one embodiment. Thecode1030 may include instructions for performing embodiments of one or more of the methods described above. Thus, the illustratedcode1030 may implement the logic architecture24 (FIG. 3) and may be similar to the code213 (FIG. 6), already discussed. Further, an audio I/O1024 may be coupled tosecond bus1020.
• Note that other embodiments are contemplated. For example, instead of the point-to-point architecture ofFIG. 7, a system may implement a multi-drop bus or another such communication topology. Also, the elements ofFIG. 7 may alternatively be partitioned using more or fewer integrated chips than shown inFIG. 7.
• Technologies described herein may therefore reduce cost by enabling general purpose devices such as smart phones, smart tables, etc., to be used for authentication purposes in a vehicle context. In addition, delays associated with replacing lost or stolen authentication devices may be significantly reduced due to the ability to pair a wide variety of devices with the vehicle on-the-fly. Moreover, the use of customizable profiles and/or policies to apply security constraints may be much more convenient to users and may substantially enhance the user experience. In addition, the mobile devices may be configured to communicate directly with the vehicle so that proximity status information can be determined between a general purpose mobile device and the vehicle without involving an intermediary such as a server and/or service provider.
• Examples may include an apparatus having a first factor module to determine a first proximity status of a first mobile device with respect to a vehicle and a second factor module to determine a second proximity status of a second mobile device with respect to the vehicle. The apparatus may also include a security module to configure an accessibility of one or more functions of the vehicle based at least in part on the first proximity status and the second proximity status.
• Additionally, the security module may identify a policy associated with one or more of the first mobile device and the second mobile device, wherein the accessibility is to be configured further based on the policy.
• Additionally, the security module may receive a user request via a user interface of one or more of the first mobile device, the second mobile device and the vehicle, wherein the accessibility is to be configured in response to the user request.
• Moreover, the security module may include a denial component to deny the user request if the first proximity status and the second proximity status do not satisfy a multi-factor condition of the policy.
• In addition, the security module may include a grant component to grant the user request if the first proximity status and the second proximity status satisfy a multi-factor condition of the policy.
• In addition, the grant component may apply one or more of a time constraint of the policy, a location constraint of the policy, and a login constraint of the policy to at least one of the one or more functions of the vehicle.
• Moreover, the security module may include a notification component to generate a notification via a user interface of one or more of the first mobile device, the second mobile device and the vehicle if either the first proximity status indicates that the first mobile device is not present or the second proximity status indicates that the second mobile device is not present.
• Additionally, at least one of the one or more functions of the vehicle may include one or more of a door unlock function, a trunk unlock function, an ignition function, a user setting function, a vehicle operation function, and a replacement device pairing function.
• Additionally, any of the aforementioned apparatus examples may further include a proximity sensor, wherein the first factor module is to use the proximity sensor to determine the first proximity status and the second factor module is to use the proximity sensor to determine the second proximity status.
• Examples may also include a method in which a first proximity status of a first mobile device is determined with respect to a vehicle. The method may also provide for determining a second proximity status of a second mobile device with respect to the vehicle, and configuring an accessibility of one or more functions of the vehicle based at least in part on the first proximity status and the second proximity status.
• Additionally, the method may further include identifying a policy associated with one or more of the first mobile device and the second mobile device, wherein the accessibility is configured further based on the policy.
• Additionally, the method may further include receiving a user request via a user interface of one or more of the first mobile device, the second mobile device and the vehicle, wherein the accessibility is configured in response to the user request.
• Moreover, configuring the accessibility may include denying the user request if the first proximity status and the second proximity status do not satisfy a multi-factor condition of the policy.
• In addition, configuring the accessibility may include granting the user request if the first proximity status and the second proximity status satisfy a multi-factor condition of the policy.
• In addition, configuring the accessibility may further include applying one or more of a time constraint of the policy, a location constraint of the policy, and a login constraint of the policy to at least one of the one or more functions of the vehicle.
• Moreover, configuring the accessibility may include generating a notification via a user interface of one or more of the first mobile device, the second mobile device and the vehicle if either the first proximity status indicates that the first mobile device is not present or the second proximity status indicates that the second mobile device is not present.
• Additionally, in any of the aforementioned method examples, at least one of the one or more functions of the vehicle may include one or more of a door unlock function, a trunk unlock function, an ignition function, a user setting function, a vehicle operation function, and a replacement device pairing function.
• Examples may also include at least one machine readable storage medium having a set of instructions which, when executed by a processor, cause a vehicle to perform any of the aforementioned method examples.
• Moreover, examples may include a system having a proximity sensor and a first factor module to use the proximity sensor to determine a first proximity status of a first mobile device with respect to a vehicle. The system may also have a second factor module to use the proximity sensor to determine a second proximity status of a second mobile device with respect to the vehicle, and a security module to configure an accessibility of one or more functions of the vehicle based at least in part on the first proximity status and the second proximity status.
• Examples may also include a mobile device having a policy repository to store a policy with a multi-factor condition. The mobile device may also include a wireless interface to receive a request from a security module of a vehicle and transmit the policy to the security module in response to the request.
• Additionally, the multi-factor condition may indicate whether one or more functions are to be accessible if either the first mobile device or a second mobile device are not in proximity of the vehicle.
• Additionally, the mobile device may further include a pairing module to pair the first mobile device with the vehicle.
• Moreover, the pairing module may receive a passcode via a user interface of the first mobile device, wherein the first mobile device is to be paired with the vehicle only if the passcode satisfies a login constraint of the policy.
• In addition, the wireless interface may receive a notification that the first mobile device is a master device, wherein the policy is to include a plurality of user profiles.
• In addition, the wireless interface of any of the aforementioned mobile device examples may receive a notification that either the first mobile device or the second mobile device is not within proximity of the vehicle during an attempted access of one or more functions of the vehicle.
• Examples may also include at least one machine readable storage medium comprising a set of instructions which, when executed by a processor, cause a first mobile device to perform methods of any of the aforementioned mobile device examples.
• Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chip sets, and so forth. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints.
• One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.
• Embodiments of the present invention are applicable for use with all types of semiconductor integrated circuit (“IC”) chips. Examples of these IC chips include but are not limited to processors, controllers, chipset components, programmable logic arrays (PLAs), memory chips, network chips, and the like. In addition, in some of the drawings, signal conductor lines are represented with lines. Some may be different, to indicate more constituent signal paths, have a number label, to indicate a number of constituent signal paths, and/or have arrows at one or more ends, to indicate primary information flow direction. This, however, should not be construed in a limiting manner. Rather, such added detail may be used in connection with one or more exemplary embodiments to facilitate easier understanding of a circuit. Any represented signal lines, whether or not having additional information, may actually comprise one or more signals that may travel in multiple directions and may be implemented with any suitable type of signal scheme, e.g., digital or analog lines implemented with differential pairs, optical fiber lines, and/or single-ended lines.
• Example sizes/models/values/ranges may have been given, although embodiments of the present invention are not limited to the same. As manufacturing techniques (e.g., photolithography) mature over time, it is expected that devices of smaller size may be manufactured. In addition, well known power/ground connections to IC chips and other components may or may not be shown within the figures, for simplicity of illustration and discussion, and so as not to obscure certain aspects of the embodiments of the invention. Further, arrangements may be shown in block diagram form in order to avoid obscuring embodiments of the invention, and also in view of the fact that specifics with respect to implementation of such block diagram arrangements are highly dependent upon the platform within which the embodiment is to be implemented, i.e., such specifics should be well within purview of one skilled in the art. Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the invention, it should be apparent to one skilled in the art that embodiments of the invention can be practiced without, or with variation of, these specific details. The description is thus to be regarded as illustrative instead of limiting.
• Some embodiments may be implemented, for example, using a machine or tangible computer-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform a method and/or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.
• Unless specifically stated otherwise, it may be appreciated that terms such as “processing,” “computing,” “calculating,” “determining,” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulates and/or transforms data represented as physical quantities (e.g., electronic) within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices. The embodiments are not limited in this context.
• The term “coupled” may be used herein to refer to any type of relationship, direct or indirect, between the components in question, and may apply to electrical, mechanical, fluid, optical, electromagnetic, electromechanical or other connections. In addition, the terms “first”, “second”, etc. may be used herein only to facilitate discussion, and carry no particular temporal or chronological significance unless otherwise indicated.
• Those skilled in the art will appreciate from the foregoing description that the broad techniques of the embodiments of the present invention can be implemented in a variety of forms. Therefore, while the embodiments of this invention have been described in connection with particular examples thereof, the true scope of the embodiments of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, specification, and following claims.

Claims (13)

We claim:

1. At least one machine readable storage medium comprising a set of instructions which, when executed by a processor, cause a first mobile device to:

store a policy including a multi-factor condition, wherein the policy is to define which function of a vehicle is to be accessible when the multi-factor condition is met for a specified user of the vehicle;

receive a request from a security module of the vehicle; and

transmit the policy to the security module in response to the request.

2. The at least one medium ofclaim 1, wherein one multi-factor condition of a plurality of multi-factor conditions is to be associated with one specified user of a plurality of specified users which when met is to allow one or more functions of the vehicle to be accessible to the one specified user.

3. The at least one medium ofclaim 1, wherein the instructions, when executed, cause the first mobile device to:

complete a pairing process with the vehicle; and

implement a designation as a primary device, wherein the designation as the primary device is to allow the first mobile device to be used to pair a third device with the vehicle.

4. The at least one medium ofclaim 3, wherein the instructions, when executed, cause the first mobile device to replace a second device with a third device when the second device is needed to satisfy the multi-factor condition and is not present.

5. The at least one medium ofclaim 1, wherein the instructions, when executed, cause the first mobile device to receive a notification that either the first mobile device or a second device that are each needed to satisfy the multi-factor condition are not within proximity of the vehicle during an attempted access of one or more functions of the vehicle.

6. At least one machine readable storage medium comprising a set of instructions which, when executed by a processor, cause a vehicle to:

identify a policy including a multi-factor condition, wherein the policy is to define which function of the vehicle is to be accessible when the multi-factor condition is met for a specified user of the vehicle; and

configure an accessibility of one or more functions of the vehicle when the multi-factor condition is met.

7. The at least one machine readable storage medium ofclaim 6, wherein the instructions, when executed, cause the vehicle to grant access to the one or more functions of the vehicle when a first proximity status of a first device and a second proximity status of a second device indicate that the multi-factor condition is met.

8. The at least one medium ofclaim 6, wherein one multi-factor condition of a plurality of multi-factor conditions is to be associated with one specified user of a plurality of specified users which when met is to allow one or more functions of the vehicle to be accessible to the one specified user.

9. The at least one machine readable storage medium ofclaim 8, wherein the instructions, when executed, cause the vehicle to apply one or more of a time constraint of the policy, a location constraint of the policy, and a login constraint of the policy to at least one of the one or more functions of the vehicle.

10. The at least one machine readable storage medium ofclaim 9, wherein the time constraint is to include a period of time for the specified user within which the specified user is to be allowed to access the function.

11. The at least one machine readable storage medium ofclaim 9, wherein the location constraint to include a geographic location for the specified user within which the specified user is to be allowed to access the function.

12. The at least one machine readable storage medium ofclaim 6, wherein the instructions, when executed, cause the vehicle to generate a notification via a user interface of one or more of a first mobile device, a second device and the vehicle if the first mobile device is not present or the second mobile device is not present.

13. The at least one machine readable storage medium ofclaim 6, wherein at least one of the one or more functions of the vehicle includes one or more of a door unlock function, a trunk unlock function, an ignition function, a user setting function, a vehicle operation function, and a replacement device pairing function.

Images