Patent Application
20220311775
The present invention relates generally to mobile computing devices, and more specifically, to a computerized system and method having a graphical user interface for managing access to software applications or other computer resources on computing devices using a sensor/device for capturing behavioral information, so that sensor-verified data of desired behavior is required to obtained desired access to the software/computer resource.
There is generally a need for security and access control for computing devices, including mobile computing devices such as smartphones, tablet computers, etc., as well as for personal computing devices such as desktop personal computers (PCs), laptop/notebook computers, and the like. There is currently a broad range of security measures implemented for computing devices. For example, access to the operating system, software applications, functionality and/or other resources of a smartphone device or a personal computer may be password-protected, such that a person needs to provide a pre-determined password to gain access to the computer resources, and such that access will be provided (e.g., the computing device will be “unlocked”) only if an expected/approved/suitable password is provided. Two-factor authentication systems often involve not only a password, but also an access code sent at the time of an access request, and those access codes may be delivered via a smartphone or other computing device, an electronic “fob” or other hardware. Access to individual software applications of a computer system may similarly be secured, and require a suitable password, access code, etc.
Further, some computing devices may be secured by sensor hardware designed to gather unique biometric information, e.g., via a retinal scan or a fingerprint scan, to otherwise confirm that the person attempting access is in fact an approved/authorized person with suitable credentials.
In these cases, however, the security measures are generally designed to limit access to computers and their software to only those persons that are authorized to have such access.
Further, it is noted that people are increasingly engaged with computing devices, and particularly with smartphone and similar types of computing devices not only for work/business purposes, but also for personal and recreational purposes. For example, it has been estimated that approximately 81% of U.S. adults own a smartphone and 90% of the time people spend on their smartphones involves using mobile software applications (“apps”). In an exemplary survey, 96% of people reported that they use messaging apps, 81% used mobile games apps, 70% used social networking apps, 47% used retail apps, and 40% used their mobile phones to read the news. Further still, it has been noted that many people have behaviors that they wish to decrease, such as smoking, vaping, alcohol and/or cannabis consumption, etc., and/or increase, such as exercise, weight loss, medication regimen adherence, homework completion, chore completion, etc. for medical, health and wellness, or other purposes.
What is needed is a system and method providing a user interface for management of access to computing device resources that can help to achieve desired changes in behavior.
The present invention provides a computerized system and method providing a user interface for management of access to computing device resources that can help to achieve desired changes in behavior, by using sensor-based hardware to assess aspects of behavior and to selectively grant or deny desired access to computing device resources based on sensor-gathered data, e.g., in comparison to predetermined behavior goals. In this manner, for example, the access control measures limit access to computing device resources not based solely on the identity of a person (e.g., a person that is authorized to have such access), but rather based on the behavior of a person (as captured objectively by a sensor), e.g., in relation to predetermined behavior goals.
In part, the present invention captures an opportunity to use access to desired mobile computing device apps as a low-cost, non-monetary incentive for beneficial behavior modification purposes.
For a better understanding of the present invention, reference may be made to the accompanying drawings in which:
According to illustrative embodiment(s) of the present invention, like reference numerals are used consistently throughout to refer to like and corresponding parts of the invention for all of the various views and figures of the drawings.
The following detailed description of the invention contains many specifics for the purpose of illustration. Any one of ordinary skill in the art will appreciate that many variations and alterations to the following details are within scope of the invention. Accordingly, the following implementations of the invention are set forth without any loss of generality to, and without imposing limitations upon, the claimed invention.
An exemplary embodiment of the present invention is discussed below for illustrative purposes.
In accordance with a certain aspect of the present invention, one or more of the Computing Devices 90a, 90b may store and execute an “app” or other purpose-specific application software in accordance with the present invention, although this is not required in all embodiments.
In accordance with the present invention, the exemplary network computing environment 100 further includes at least on Sensor Device 10a, 10b. The
Sensor Device may be, or may include, any suitable sensor for measuring/recording behavior of a person and/or the person's activities in relation to any desired behavior. Various conventional and suitable sensors are commercially available. For example, suitable hardware sensors may be, or may be incorporated into, a scale for measuring a person's weight, a camera for capturing still images or recording video images, a wearable activity tracker such as a Fitbit or Apple Watch, a breathalyzer or breath analysis test for measuring a blood alcohol level associated with alcohol drinking, a carbon monoxide detector for measuring a carbon monoxide level associated with smoking, an electronic pill dispenser, etc. Alternatively, the Sensor Device (which is shown separately for illustrative purposes only in
In accordance with the present invention, the exemplary network computing environment 100 further includes an Access Management System (AMS) 200. In this exemplary embodiment, the AMS 200 is operatively connected to the Computing Devices 90a, 90b and the Sensor Device 10b for data communication via the communications network 50. For example, the AMS 200 may gather user data or other inputs from each device 90a, 90b, as well as generated data generated by the Sensor Device 10b by data communication via the communications network 50. Hardware and software for enabling communication of data by such devices via such communications networks are well known in the art and beyond the scope of the present invention, and thus are not discussed in detail herein.
By way of example, the present invention may be implemented to perform a gatekeeper function for access to computer resources, such as a smartphone “app” or other application software, of the Computing Devices 90a, 90b, whether the gatekeeper function is provided at least in part by software at a remotely located AMS as shown in the example of
In this exemplary embodiment, the AMS 200 includes the system components providing the gatekeeper functionality, but in other embodiments, the user's Personal Computing Device 90a or Mobile Computing Device 90b may be configured with the gatekeeper functionality of the AMS 200 and some or all of the components shown in
Accordingly, the exemplary AMS 200 of
The AMS 200 may communicate with other computers or networks of computers, for example via a communications channel, network card or modem 220. The AMS 200 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), and may operate as a server in a client/server arrangement with another computer, etc. Such configurations, as well as the appropriate communications hardware and software, are known in the art.
The AMS 200 is specially-configured in accordance with the present invention. Accordingly, as shown in
Further, as will be noted from
As shown in
In accordance with the present invention, the exemplary embodiment of the AMS 200 shown in
In accordance with the present invention, the exemplary embodiment of the AMS 200 shown in
In certain embodiments, the RSM 260 is configured to programmatically identify a particular computer resource to be subjected to this conditional access. By way of example, the RSM 260 may be configured to choose different computer resources over time, on a rotating basis, or to choose one randomly, or to choose one according to predetermined logic. In other embodiments, the RSM 260 is configured to track the past usage of and/or currently running computer resources (e.g., apps) and to identify a set of more frequently used computer resources. This informs the RSM 260 as to which apps/computer resources are candidates for behavior-based access controls. Further, the RSM 260 is configured to display a list of the more frequently used computer resources via a display device of the user's Computing Device and to permit the user to select from the displayed list (by providing input to the computing device) a specific computer resource to which the gatekeeper/conditional access functionality will be applied, so that the user's selected computer resource will be subjected to the behavior-based conditional access controls. For example, a user that likes to frequently use a particularly social media app may choose that app to be access-controlled by the gatekeeper/conditional access functionality consistent with the present invention, such that the user will be incentivized to maintain a desired behavior so that readings confirming the desired behavior can be recorded by the relevant sensor to unlock access to the social media app. Accordingly, the user's desire for the app can be used as a driver to help the user in making desired behavioral modifications. The RSM 260 in conjunction with the Display Module 290 may cause display of windows requiring the user to take actions and provide inputs to the operating system software via the graphical user interface to grant permissions necessary to implement the blocking functionality, according to the particular implementation for a particular computing device.
In certain embodiments, the RSM 260 may be configured to include or exclude certain computer resources from a list of user-selectable computer resources, e.g., based on the criticality of access to the resource, e.g., to exclude a particular resource from eligibility for access controls if it is deemed important for the user to have access to that resource at all times. For example, the RSM 260 may be configured to never subject an important and/or safety-related computer resource to be subjected to such conditional access, but may permit non-essentially/recreational computer resources to be subjected to such conditional access. After a particular computer resource, or parameters for selecting a computer resource, have been identified, those selections/parameters may be stored as Resource Data 224d in the Data Store 224. These selections may vary on a per-user basis, and may vary over time for a single user, and may be reflected in the Resource Data 224d and/or in the User Data 224a.
In accordance with the present invention, the exemplary embodiment of the AMS 200 shown in
In certain embodiments, it is desirable to gather behavior data via the sensor at regular or prescribed intervals, and to allow conditional access of computer resources at any time. In such embodiments the AMM 270 determines when it is time to gather behavior data, determines which sensor is relevant if needed, and prompts the Sensor Module 280 to gather relevant data via the relevant sensor. Further, in addition to comparing the gathered behavior data to the reference data, the AMM 270 determines whether the comparison indicates the desired behavior as a function of whether or not the sensor-gathered data indicates behavior that is, or is not, consistent with the user's behavior objective. Further still, as part of selectively permitting or denying access to the computer resources, the AMM 270 stores a balance of earned tokens for the user (e.g., stored as User Data 224a) and adds tokens to the balance (according to any desired logic) when the gathered behavior data from the sensor is determined to show that the user's behavior is consistent with the user's behavior objective. Optionally, the AMM 270 may cause display of a message indicating non-compliance with the behavior objective in the event that the gathered behavior data from the sensor is determined not to show that the user's behavior is consistent with the user's behavior objective. Subsequently, in response to a request to access a computer resource subject to behavior-based access control, the AMM 270 blocks the user's access to the computer resource until after sufficient earned tokens have been tendered (such that the user's behavior consistent with the behavior objective and observed/captured by the sensor has earned the user the ability to access the computer resource subject to the behavior-based access control). The AMM 270 denies access to the computer resource if the user attempt to tender the tokens, or does not have sufficient tokens to “purchase” access. The AMM 270 permits access to the computer resource if the user attempts to tender the tokens and has sufficient tokens to “purchase” access, and subtracts the tendered tokens from a token balance. Preferably, access is permitted for only a limited period of time (e.g., a single session, a few hours, a day, etc.) after which access is no longer permitted as part of the initial access “purchase.” This provides a continuing incentive for the user to continue the desired behavior over time, to be able to continue to access the access-controlled resource over time. In certain embodiments, earned tokens may be subtracted (according to any desired logic) from the token balance over time, to prevent the user from “banking” so many tokens that user is disincentivized to continue the desired behavior. Such an embodiment is discussed below with reference to
Any suitable approach may be provided to implement the functionality of the AMM 270, and the approaches may vary depending upon the computing device, operating system and/or environment in which the AMM 270 is operated. Similarly, the AMM 270 is configured to discontinue its blocking of access to the computer resource when it detects that sufficient tokens have been tendered.
In accordance with the present invention, the exemplary embodiment of the AMS 200 shown in
In accordance with the present invention, the exemplary embodiment of the AMS 200 shown in
With respect to the description of the exemplary embodiment above, it should be further noted that in certain other embodiments, some the functions described above may be omitted, and instead of providing a user with choices of behavior modification objective, sensor type, resource to be controlled, etc. those parameters may be hard-coded into the application software, such that there is no need to gather input from a user. For example, a certain application may be dedicated to a single behavior modification objective. Also, in other embodiments, the various components and/or functionality of the IME 230 described above may be incorporated into a software application at the Computing Device 90a, 90b, such that there is a reduced need or no need for involvement of a remotely-located AMS 200 to gather such information. Rather, these functions may be managed partly or solely at the Computing Device 90a, 90b, by software at the Computing Device.
Next, the method involves identification of a suitable sensor device corresponding to the behavior modification objectives, as shown at 304. As described above, this may be performed by the SIM 250, and may be performed according to a user's selection of a particular sensor device, or may be based upon the user's selection of a behavior modification objective, or may be done automatedly/programmatically.
Next, the method involves identification of computer resources to be subject to behavior-based access control, as shown at 306. As described above, this may be performed by the RSM 260, and may be performed according to a user's selection of a particular computer resources (such as a particular app), or may be done automatedly/programmatically, including randomly, or according to predetermined logic. If this identification is being done by the software/system, then the software/system automatedly selects a particular computer resources to be subject to behavior-based access control, as shown at 308 and 310. Alternatively, if this identification is not being done by the software/system, then the software/system receives a user's selection/specification of a particular computer resource to be subjected to behavior-based access control, as shown at 208 and 312. For example, the particular resource to be subjected to behavior-based access control may vary over time, and may be, for example, a particular software application/app.
The method then involves receiving a request to access a computer resource. The AMM 270 may determine whether the request is a request to access the particular resource to be subject to behavior-based access control.
In one embodiment, when a request to access the particular computer resource to be subject to behavior-based access control is received, the AMM 270 may then cause display of a graphical user interface window prompting the user to provide input via the appropriate sensor device, as shown at 314 and 316. This may involve determining which sensor is appropriate for the user, behavior objective, etc., and causing prompts to be displayed at the Computing Device 90a, 90b, for gathering appropriate data via the sensor. This may be performed by, or at least in part by, the SM 290 in conjunction with the AMM 270.
The AMM 270 then compares the behavior data gathered via the sensor device to reference data, as shown at 318. This may involve retrieval of suitable Reference Data 224f for the relevant sensor and/or User Data 224a for the relevant user from the data store 224. The AMM 270 then compares the gathered data and the reference data and determines whether the comparison indicates the desired behavior in view of the behavior modification objective, as shown at 320. For example, for a smoking cessation or alcohol cessation goal, this may involve a sensor reading less than a threshold value for the device, and for a weight loss goal, for example, this may involve a sensor reading less than a threshold value for the user.
If it is determined that the comparison indicates that the user's behavior is consistent with desired behavior according to the behavior modification objective (e.g., no detection of alcohol in a breath sample), then access to the access-controlled computer resource is permitted, as shown at 320 and 322, and the method ends, as shown at 324. For example, if permitted, the user may be granted access to use his/her favorite smartphone app because it has been confirmed that the user's behavior has been consistent with the behavior modification objective. The user may then use the controlled computer resource in the desired fashion. This may continue for unlimited or for a limited time, e.g., the duration of a current session, or a particular timeframe. If however, it is determined that the user's behavior is not consistent with desired behavior according to the behavior modification objective (e.g., alcohol was detected in a breath sample), then access to the access-controlled computer resource is denied, as shown at 320 and 326, and the method ends, as shown at 324. In this case, for example, if denied, the user's attempt to open an app or otherwise be granted access to a desired computer resource will not be effective to gain access to/use that computer resource.
In certain embodiments, tokens may be earned and exchanged to unblock access to the app(s)/computer resources, contingent upon objective evidence (provided by hardware sensors or other mechanisms) of goal achievement, such as smoking abstinence (carbon monoxide [CO] <4 ppm). Such an alternative exemplary embodiment is discussed below with reference to
When it is determined at 402 that it is time to gather behavior data, in this exemplary embodiment the AMS 200 (e.g., the AMM 270) next identifies the relevant sensor for use by the user to gather the relevant behavior data, as shown at 404. By way of example, this may be performed by the AMM 270 by referring to the stored User Data 224a, or Sensor Type Data 224c.
The AMS 200 then displays a prompt to prompt the user to submit behavior data via the sensor, as shown at 406. By way of example, this may be performed by the DM290 acting in concert with the AMM 270 to cause display of a graphical user interface window displaying text or images indicating to the user that it is time to submit behavior data via the sensor.
The user may then provide input (e.g., via touchscreen of the Computing Device 90b) to clear the graphical user interface window containing the prompt (e.g., by clicking the checkmark) and the provide input by selecting the Submit a CO Sample button 630 displayed in the graphical user interface window 600 to initiate a process for submitting a sample (e.g., blowing into a CO sensor 10a operatively connected to the Computing Device 90b) to cause the sensor 10a to gather behavior data (here, CO level data in the breath sample) associated with the sample. Accordingly, the method next involves receiving the behavior data via the sensor device 10a, as shown at 408. This may be performed and/or managed by the Sensor Module 280.
The method then involves retrieval of Reference Data 224f stored in the Data Store 224 for the user and/or the particular sensor device (e.g., CO sensor), as shown at 410. This may be performed by the AMM 270, as described above. For example, the reference data may indicate thresholds for CO level data indicating compliance and/or non-compliance with the behavior modification objective (e.g., smoking cessation).
The method then involves comparing the gathered behavior data from the sensor to the retrieved Reference Data 224f, as shown at 412. This may be performed by the AMM 270, as described above.
If the AMM 270 determines that the comparison does not indicate the desired behavior at 414 (e.g., the gathered data indicates a CO level associated with smoking behavior), then a graphical user interface window may be displayed (e.g., by the AMM 270 acting in concert with the DM 290) to display a message indicating non-compliance with the desired behavior. This data may be stored in association with the user in the User Data 224a of the Data Store 224 for future reference, graphing, etc., and method flow may return to 402 until the next occurrence of a time to gather behavior data/submit a behavior-related sample to a relevant sensor.
If, however, the AMM 270 determines that the comparison does indicate the desired behavior at 414 (e.g., the gathered data indicates a CO level associated with non-smoking behavior), then the user will be rewarded by increasing a balance of earned tokens available for use to “purchase” access to a computer resource subject to behavior-based access control in accordance with the present invention. The increase maybe applied according to any suitable logic. The increase maybe applied by the AMM 270, and data associated with the current balance may be stored in association with the user in the User Data 224a of the Data Store 224 for future reference, graphing, etc. The current balance of tokens may be displayed in the Token Balance panel 640 by the DM 290 (which may reference the current balance stored as User Data 224a in the Data Store 224), as shown in
The window may be displayed on the user's Computing Device, such as window 600 displayed on Mobile Computing Device 90b in the example shown in
Referring now to
The method then proceeds to 512, which is described above with reference to 312 of
In response to this request (e.g., tapping an app's icon displayed on a touchscreen of a computing device or otherwise initiating access to a computer resource), the DM 290, acting in concert with the AMM 270, displays a prompt for the user to tender tokens in order to gain access the computer resource, as shown at 522.
The method then proceeds to 524, where it is determined whether the user has attempted to tender tokens, as shown in
If it is determined at 524 that the user has not attempted to tender the tokens (e.g., because the user choose not to “spend” tokens at this time), then the computer resource remains blocked, and thus the user is denied access to the desired computer resource, as shown at 526, and this exemplary instance of the method ends, as shown at 534, although during normal operation all or portions the exemplary methods of
If, however, it is determined at 524 that the user has attempted to tender tokens (e.g. because the user wishes to access the resource at this time), then the system determines whether the user has a sufficient quantity of tokens in the user's token balance, as shown at 528. This may be performed by the AMM 270 with reference to the User Data 224a stored in the Data Store 224, as described above.
If it is determined at 528 that the user does not have a sufficient quantity of tokens in the user's token balance, then the computer resource remains blocked, and thus the user is denied access to the desired computer resource, as shown at 526, and this exemplary instance of the method ends, as shown at 534.
Accordingly, the user is thereby denied access to a computer resource that the user wishes to access, which provides an incentive in furtherance of the behavior modification objective, namely, to maintain behavior compliant with the behavior modification objective, earn tokens as a result, and have tokens to apply to “purchase” access to the computer resource that the user wishes to access.
If, however, it is determined at 528 that the user does have a sufficient quantity of tokens in the user's token balance (as in the example of
The AMM 270 then permits access to the behavior-based access controlled computer resource, as shown at 532, and the method ends as shown at 534. This may involve the DM 290, acting in concert with the AMM 270, displaying a new updated current token balance (40 tokens) in the Token Balance panel 640, as well as indicating that the resource (e.g., App. #1) now has an unlocked status in Resource Status panel 610, as shown in
Accordingly, it will be appreciated that the present invention provides a computerized system and method for behavior-based access control management for application software or other resources of computing devices, and to do so by using the user's desire to access those resources as a non-monetary incentive for health-related or other behavior modification, to the benefit of the user.
The various implementations and examples shown above illustrate a method and system for performing a sensor-based access control management for computing device resources. As is evident from the foregoing description, certain aspects of the present implementation are not limited by the particular details of the examples illustrated herein, and it is therefore contemplated that other modifications and applications, or equivalents thereof, will occur to those skilled in the art. It is accordingly intended that the claims shall cover all such modifications and applications that do not depart from the spirit and scope of the present implementation. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Certain systems, apparatus, applications or processes are described herein as including a number of modules. A module may be a unit of distinct functionality that may be presented in software, hardware, or combinations thereof. When the functionality of a module is performed in any part through software, the module includes a computer-readable medium. The modules may be regarded as being communicatively coupled. The inventive subject matter may be represented in a variety of different implementations of which there are many possible permutations.
The methods described herein do not have to be executed in the order described, or in any particular order. Moreover, various activities described with respect to the methods identified herein can be executed in serial or parallel fashion. In the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter may lie in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
In an exemplary embodiment, the system may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the system may operate in the capacity of a server or a client system in server-client network environment, or as a peer system in a peer-to-peer (or distributed) network environment. The system may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a smart phone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system or computing device. Further, while only a single system is illustrated, the term “system” shall also be taken to include any collection of system that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The exemplary computer system and client computers include a processor (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory and a static memory, which communicate with each other via a bus. The computer system may further include a video/graphical display unit (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system and client computing devices also include an alphanumeric input device (e.g., a keyboard or touch-screen), a cursor control device (e.g., a mouse or gestures on a touch-screen), a drive unit, a signal generation device (e.g., a speaker and microphone) and a network interface device.
The system may include a computer-readable medium on which is stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or systems described herein. The software may also reside, completely or at least partially, within the main memory and/or within the processor during execution thereof by the computer system, the main memory and the processor also constituting computer-readable media. The software may further be transmitted or received over a network via the network interface device.
The term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present implementation. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical media, and magnetic media.
This application claims the benefit of U.S. Provisional Patent Application No. 63/166,647, filed Mar. 26, 2021, the entire disclosure of which is hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63166647 | Mar 2021 | US |
