Systems, apparatus and methods for risk-adjusted dynamic access & control for drug delivery devices

Abstract

A dynamic risk-adjusted access and control platform for drug delivery devices and associated consumable products is disclosed. The system includes requesting devices operable to generate requests triggered by request events made by requesting users. The platform also comprises a risk engine adapted to receive the request information from the requesting devices, behavioral information relating to operational characteristics of one or more devices associated with registered users and intrinsic information associated with personal characteristics of registered users. The risk engine is further adapted to infer risk scores associated with the registered users based on the request information, the behavioral information, and the intrinsic information, and the system is adapted to accept or deny the requests based on these risk score.

Description

SYSTEMS, APPARATUS AND METHODS FOR RISK-ADJUSTED DYNAMIC ACCESS & CONTROL FOR DRUG DELIVERY DEVICESCROSS-REFERENCE TO PREVIOUS APPLICATON

[0001] This application claims priority from United States provisional patent application 63 / 568,706 filed on March 22nd, 2024, which is incorporated herein by reference in its entirety.FIELD

[0002] The present disclosure generally relates to the field of drug delivery devices. In particular, various embodiments are described herein that relate to systems, apparatus and methods for risk-adjusted dynamic access and control for drug delivery devices.INTRODUCTION

[0003] The following paragraphs are provided by way of background to the present disclosure. They are not, however, an admission that anything discussed therein is prior art or part of the knowledge of persons skilled in the art.

[0004] Electronic vapor delivery devices are increasingly popular. Such devices have been developed for inhalation-based delivery of cannabis components and nicotine. As the ubiquity of such devices has increased, so have concerns about their misuse. For example, use of vaporizer devices among underage users has become a concern for parents, schools and regulators.

[0005] Known efforts to restrict access to vaporizer devices and products have often resulted in significant reductions in the ease of purchase and use of such devices and products for legitimate users. The technical problems associated with the tradeoffs between restricting misuse and ensuring frictionless legitimate use are compounded by significant price sensitivity in the market, resulting in most consumers not being willing to pay for vaporizer devices equipped with the required technology (e.g., sophisticated communication sensors and displays, as well as the underlying processing resources required to manage them) to address this issue.

[0006] Some device manufactures have attempted to solve this problem by leveraging mobile device authentication to provide vaporizer access control. Such efforts however have been hampered by some mobile device manufacturers’ reluctance to allowthe distribution of applications (also known as “apps”) associated with vaporizers on their digital distribution platforms (also known as “app marketplaces” or “app stores”).

[0007] Moreover, even solutions that are able to leverage mobile device authentication remain static access control solutions, meaning that they do not adapt to varying levels of risky behavior or device use with proportionally onerous authentication and access control.

[0008] There is therefore a clear need for systems, apparatus and methods for risk- adjusted dynamic access and control for vaporizer devices that address the challenges and / or shortcomings described above and provide effective access control and frictionless use for legitimate adult users.SUMMARY

[0009] Various embodiments of a platform for controlling access to vaporizer devices, authorizing transactions of vaporizer device products and authenticating users of vaporizer devices are provided according to the teachings herein. Various operations of platforms described herein use a risk engine that dynamically rates the risk associated with the user of the platform. This dynamically adjusted risk assessment is then used by the platform to authenticate users of vaporizer devices, authorize purchases of vaporizer device products and control access to the functionality of vaporizer devices.

[0010] According to an aspect of the present disclosure, there is disclosed a dynamic risk assessment system for drug delivery devices and associated consumable products. The system comprises a requesting device operable to generate a request triggered by a request event made by a requesting user, the request comprising request information relating to the request event and being associated with a registered user of the system. The system also comprises a risk engine adapted to receive the request information from the requesting device, behavioral information relating to operational characteristics of one or more devices associated with the registered user, and intrinsic information associated with personal characteristics of the registered user. The risk engine is further adapted to infer a risk score associated with the registered user based on the request information, the behavioral information, and the intrinsic information, and the system is adapted to accept or deny the request based on the risk score.

[0011] In some examples, the requesting device is a drug delivery device.

[0012] In some examples, the drug delivery device is a vaporizer device.

[0013] In some examples, the request event is a request initiated by an action of the user to unlock a drug delivery device.

[0014] In some examples, the request information comprises a unique ID associated with the requesting device and a challenge value generated by the requesting device.

[0015] In some examples, the request information further includes a risk score generated by the requesting device, the risk score being based on one or more usage characteristics of the requesting device.

[0016] In some examples, the requesting device is a point of sale (POS) device.

[0017] In some examples, the request event is a request to purchase a consumable product associated with the drug delivery device.

[0018] In some examples, the request information includes point of sale (POS) information.

[0019] In some examples, the point of sale (POS) information includes one of more of time and date information, location information, and stock keeping unit (SKU) information.

[0020] In some examples, the risk engine comprises one or more machine learning models.

[0021] In some examples, the behavioral information includes information relating to actions taken by the requesting user and / or the registered user.

[0022] In some examples, the information relating to actions taken by the requesting user and / or the registered user include usage patterns of a drug delivery device and / or transaction patterns relating to an associated consumable product.

[0023] According to another aspect of the present disclosure, there is provided a risk-adjusted dynamic authentication method for a drug delivery device. The method comprises receiving request information relating to a request event made by a requesting user, the request information relating to the request event and being associated with a registered user of the system. The method also comprises receiving a risk score associated with the registered user. The method also comprises selecting anauthentication process from a plurality of authentication processes based on the risk score, each of the plurality of authentication processes having a different level of security and a corresponding level of difficulty to carry out by the requesting user. The method also comprises authenticating the requesting user as being the registered user using the selected authentication process.

[0024] In some examples, the request event is a request initiated by an action of the user to unlock a drug delivery device.

[0025] In some examples, the request information comprises a unique ID associated with the requesting device and a challenge value generated by the requesting device.

[0026] In some examples, the request information further includes a device risk object generated by the drug delivery device, the device risk object being based on one or more usage characteristics of the drug delivery device.

[0027] In some examples, the request event is a request to purchase a consumable product associated with a drug delivery device.

[0028] In some examples, the request information includes point of sale (POS) information.

[0029] In some examples, the point of sale (POS) information includes one of more of time and date information, location information, and stock keeping unit (SKU) information.

[0030] In some examples, the plurality of authentication processes includes one or more of a one-time-passcode (OTP) authentication, a personal identification number (PIN) authentication, biometric authentication and likeness authentication.

[0031] In some examples, the drug delivery device is a vaporizer device.

[0032] In accordance with yet another aspect of the present disclosure, there is provided a non-transitory computer program product comprising computer-implemented instructions to cause one or more computer systems to execute the above method.

[0033] In accordance with yet another aspect of the present disclosure, there is provided an access control method for a drug delivery device. The method comprises receiving a unique device identifier associated with the drug delivery device and adynamic challenge value generated by the drug delivery device. The method also comprises retrieving a secret encryption key associated with unique device identifier. The method also comprises generating an unlock sequence based on the secret encryption key and the dynamic challenge value. The method also comprises sending the unlock sequence to the drug delivery device, the drug delivery device being operable to be unlocked when the unlock sequence is input into the drug delivery device.

[0034] In some examples, the method further comprises retrieving a unique user identifier associated with the unique device identifier and retrieving a risk score associated with the unique user identifier, the risk score being indicative of the likelihood that the drug delivery device is being user outside a set of use policies. The step of generating an unlock sequence further comprises generating the unlock sequence based on the risk score.

[0035] In some examples, the one of the policies in the set of use policies is that the drug delivery device must be used by the user associated with the unique user identifier.

[0036] In some examples, the drug delivery device is a vaporizer device.

[0037] In some examples, the step of receiving a unique device identifier associated with the drug delivery device and a dynamic challenge value generated by the drug delivery device includes receiving the unique device identifier associated with the drug delivery device and the dynamic challenge value generated by the drug delivery device via Near Field Communication (NFC) technology implemented on the drug delivery device and a mobile communication device.

[0038] In some examples, the unique device identifier associated with the drug delivery device and the dynamic challenge value generated by the drug delivery device are encoded in a Uniform Resource Locator (URL), which is configured to cause the mobile communication device to open a web application in a browser of the mobile communication device.

[0039] In some examples, the unique device identifier associated with the drug delivery device is encoded in a Uniform Resource Locator (URL), which is configured to cause the mobile communication device to open a web application in a browser of the mobile communication device. The drug delivery device is configured to display thedynamic challenge value to a user of the mobile communication device and the web application is configured to allow the user to input the dynamic challenge value into the web application.

[0040] In some examples, the unique device identifier associated with the drug delivery is encoded in a Uniform Resource Locator (URL), which is configured to cause the mobile communication device to open a web application in a browser of the mobile communication device. The drug delivery device is configured to display the dynamic challenge value to the mobile communication device, and the web application is configured to use the mobile communication device to capture the dynamic challenge value from the drug delivery device.

[0041] In some examples, the web application is configured to use the camera of the mobile communication device to capture the dynamic challenge value from the drug delivery device.

[0042] In some examples, the drug delivery device is configured to display the dynamic challenge value using a plurality of light emitting diodes (LEDs).

[0043] In some examples, the drug delivery device is configured to display the dynamic challenge value using a visual display.

[0044] In some examples, the drug delivery device is configured to generate the dynamic challenge value using a random number generator (RNG).

[0045] In some examples, the method further comprises inputting the unlock sequence into the drug delivery device.

[0046] In some examples, the step of inputting the unlock sequence is performed by the mobile communication device.

[0047] In some examples, the step of inputting the unlock sequence is performed by the mobile communication device using wireless data communication.

[0048] In some examples, the web application is operable to display the unlock sequence to the user via the mobile communication device and the step of inputting the unlock sequence is performed by the user using inputs means of the drug delivery device.

[0049] In some examples, the input means of the drug delivery device is a push button switch.

[0050] In some examples, the risk score is used by the drug delivery device to restrict access to the drug delivery device by a user.

[0051] According to another aspect of the present disclosure, there is provided a system configured to carry out the above method.

[0052] According to another aspect of the present disclosure, there is provided a non-transitory computer program product comprising computer-implemented instructions to cause one or more computer systems to execute the above method.

[0053] Other features and advantages of the present disclosure will become apparent from the following detailed description taken together with the accompanying drawings. It should be understood, however, that the detailed description and the specific examples, while indicating preferred embodiments of the application, are given by way of illustration only, since various changes and modifications within the spirit and scope of the application will become apparent to those skilled in the art from this detailed description.DRAWINGS

[0054] For a better understanding of the various embodiments described herein, and to show more clearly how these various embodiments may be carried into effect, reference will be made, by way of example, to the accompanying drawings which show at least one example embodiment, and which are now described. The drawings are not intended to limit the scope of the teachings described herein. In the drawings:

[0055] Figure 1 shows a schematic illustration of a platform in accordance with various embodiments of the present disclosure;

[0056] Figure 2 shows a schematic illustration of a dynamic risk assessment system in accordance with embodiments of the present disclosure;

[0057] Figure 3 shows a flow chart of a risk-adjusted authentication method in accordance with one example of the present disclosure;

[0058] Figure 4 shows a flow chart of a risk-adjusted access control method in accordance with one example of the present disclosure;

[0059] Figure 5 shows a communication sequence diagram illustrating a method of unlocking a vaporizer device in accordance with embodiments of the present disclosure; and

[0060] Figure 6 shows another communication sequence diagram illustrating a method of unlocking a vaporizer device in accordance with embodiments of the present disclosure.

[0061] Further aspects and features of the example embodiments described herein will appearfrom the following description taken together with the accompanying drawings.DESCRIPTION OF VARIOUS EMBODIMENTS

[0062] Various embodiments in accordance with the teachings herein will be described below to provide an example of at least one embodiment of the claimed subject matter. No embodiment described herein limits any claimed subject matter. The claimed subject matter is not limited to devices, systems, or methods having all of the features of any one of the devices, systems, or methods described below or to features common to multiple or all of the devices, systems, or methods described herein. It is possible that there may be a device, system, or method described herein that is not an embodiment of any claimed subject matter. Any subject matter that is described herein that is not claimed in this document may be the subject matter of another protective instrument, for example, a continuing patent application, and the applicants, inventors, or owners do not intend to abandon, disclaim, or dedicate to the public any such subject matter by its disclosure in this document.

[0063] It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments described herein. Also, the description is not to be considered as limiting the scope of the embodiments described herein.

[0064] It should also be noted that the terms “connected” or “connection” as used herein can have several different meanings depending on the context in which these terms are used. For example, the terms connected or connection can have a mechanical or electrical connotation. For example, as used herein, the terms connected or connection can indicate that two elements or devices can be directly connected to one another orconnected to one another through one or more intermediate elements or devices via an electrical signal, electrical connection, or a mechanical element depending on the particular context.

[0065] It should also be noted that, as used herein, the wording “and / or” is intended to represent an inclusive-or. That is, “X and / or Y” is intended to mean X or Y or both, for example. As a further example, “X, Y, and / or Z” is intended to mean X or Y or Z or any combination thereof.

[0066] Further, although method steps may be described (in the disclosure and / or in the claims) in a sequential order, such methods may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of methods described herein may be performed in any order that is practical. Further, some steps may be performed simultaneously.

[0067] The example embodiments of the devices, systems, or methods described in accordance with the teachings herein may be implemented as a combination of hardware and software. For example, the embodiments described herein may be implemented, at least in part, by using one or more computer programs, executing on one or more programmable devices comprising at least one processing element and at least one storage element (i.e., at least one volatile memory element and at least one nonvolatile memory element). The hardware may comprise input devices including one or more of a touch screen, a keyboard, a mouse, buttons, keys, sliders, and the like, as well as one or more of a display, a printer, and the like depending on the implementation of the hardware.

[0068] It should also be noted that there may be some elements that are used to implement at least part of the embodiments described herein that may be implemented via software that is written in a high-level programming language. The program code may be written in Rust, C++, C#, JavaScript, Python, or any other suitable programming language and may comprise modules or classes, as is known to those skilled in the art. Alternatively, or in addition thereto, some of these elements implemented via software may be written in assembly language, machine language, orfirmware as needed. In either case, the language may be a compiled or interpreted language.

[0069] At least some of these software programs may be stored on a computer readable medium such as, but not limited to, a ROM, a magnetic disk, an optical disc, solid-state storage, a USB key, and the like that is readable by a device having a processor, an operating system, and the associated hardware and software that is necessary to implement the functionality of at least one of the embodiments described herein. The software program code, when read by the device, configures the device to operate in a new, specific, and predefined manner (e.g., as a specific-purpose computer) in order to perform at least one of the methods described herein.

[0070] At least some of the programs associated with the devices, systems, and methods of the embodiments described herein may be capable of being distributed in a computer program product comprising a computer readable medium that bears computer usable instructions, such as program code, for one or more processing units. The medium may be provided in various forms, including non-transitory forms such as, but not limited to, one or more diskettes, compact disks, tapes, chips, and magnetic and electronic storage. In alternative embodiments, the medium may be transitory in nature such as, but not limited to, wire-line transmissions, satellite transmissions, internet transmissions (e.g., downloads), media, digital and analog signals, and the like. The computer usable instructions may also be in various formats, including compiled and uncompiled code.

[0071] As used herein, the term “static Near Field Communication” or “static NFC” means any inductive coupling technology (and the underlying set of communication protocols) that enables communication between two electronic devices over a distance of four centimeters or less, in which the memory content of the NFC device is not modified.

[0072] As used herein, the term “dynamic Near Field Communication” or “dynamic NFC” means any inductive coupling technology (and the underlying set of communication protocols) that enables communication between two electronic devices over a distance of four centimeters or less, in which the memory content of one or both of the NFC devices can be modified.

[0073] Verifying the age of a purchaser at a point-of-sale (PCS) (whether via a PCS device 180 in a physical store or on a website 190 online) is ineffective at solving the problem of underage use of age-restricted consumable products, such as nicotine and other controlled substances. Indeed, consumables and devices may be resold orotherwise transferred to a new user (e.g., an underage user) after an age-controlled purchase.

[0074] There is a clear need for ongoing age verification mechanisms throughout the lifecycle of a sold product based on dynamically evaluated risk predictors for better underage use prevention in a variety of scenarios, without penalizing any adult users acting in good faith and in a legal manner. Drawbacks of current solutions are that control is either too lenient (e.g., a single control done at POS), may not work on all user mobile devices, or would cause an undue level of user experience friction for legitimate users (e.g., the requirement for constant proximity of a user authenticated mobile device with a vaporizer device and automatic locking of the vaporizer device when proximity or connectivity is interrupted).

[0075] In order to address post-POS prevention of underage use of nicotine products (or other age restricted drugs), the present disclosure proposes a dynamic, risk- adjusted, ongoing access control system and purchase authorization system for restricted-use products. The association of a comprehensive, multi factor digital user ID, with an ongoing risk profile which is dynamically updated by an artificial intelligence (Al) engine that takes a variety of inputs into account in order to determine, on an ongoing basis, when an access control is needed and what is the appropriate level of access control required, is both novel and inventive over known solutions.

[0076] Figure 1 is a schematic illustration of an access control platform 100 for managing access to one or more drug delivery products in accordance with some embodiments of the present disclosure. As shown in Figure 1 , the platform includes an example product, a vaporizer device 121 including a vaporizer body 120 and a cartridge 130. The system 100 also includes a server 140 (e.g., a cloud-based server(s), a centralized server(s) and / or the like) in wireless network communication with a mobile device 110 (e.g., a mobile device such as a smartphone or tablet, a laptop, or a desktop computer of the user) via, for example, the Internet 160.

[0077] The cartridge 130 (also referred to as a “cartridge assembly,” a “cartridge portion,” a “capsule,” a “capsule assembly,” or a “pod”) includes a processor 132, a heating assembly 134, an input / output module 136 (referred to herein as “I / O”) for communicating, for example, with the vaporizer body 120, a reservoir 138 and a mouthpiece 133, all disposed within or coupled to a cartridge housing of the cartridge 130.The vaporizer body 120 (also referred to as a “pen portion” or a “vaporizer body”) includes, a draw sensor 123 (e.g., an airflow sensor or a pressure sensor), a power supply 124, a processor 125 (e.g., a microcontroller), an input / output module 126 (referred to herein as “I / O”), which can be used by a user to input information into the vaporizer body 120, and one or more indicators 128 all disposed within or coupled to a pen housing of the vaporizer body 120. The vaporizer body 120 can be reusable and includes an interface configured to electrically engage with the cartridge 130. The interface can include, for example, connectors (e.g., pogo pins) coupled to or included in the processor 125 and configured to engage with the cartridge 130 such that the processor 132 of the cartridge 130 is configured to receive information from the processor 125 of the vaporizer body 120 and operational power from the power supply 124 of the vaporizer body 120. The vaporizer body 120 (i.e., the pen housing and its contents) can also be referred to as a “battery portion.”

[0078] The cartridge 130 can be manufactured, shipped and / or sold separately from the vaporizer body 120. To assemble the vaporizer device 121 , a user may, prior to use (e.g., upon purchase of a new cartridge 130), couple (e.g., connect) the cartridge 130 with the vaporizer body 120. The cartridge 130 and the vaporizer body 120 can be configured to be mechanically connected, for example by one or more of screw attachment, press-fit attachment, snap-fit attachment, magnetic attachment, or any other suitable connection means. As can be inferred from the foregoing, the vaporizer body 120 can be considered the reusable portion of the vaporizer, and the cartridge 130 can be considered a disposable or “replaceable” portion of the vaporizer. When the vaporizer body 120 is coupled to the cartridge 130, under control of the processor 132 of the cartridge 130, the cartridge 130 can draw operational power from the power supply 124 of the vaporizer body 120 (e.g., to power the heating assembly 134) via the interface.

[0079] The mouthpiece 133 of the cartridge 130 can comprise one or more of: ceramic, heat-resistant plastic, anodized aluminum, or any other suitable material. The reservoir 138 is configured to receive and contain carrier material (also referred to as “carrier” or “precursor”). The carrier material can include any suitable vaporizable substance. The reservoir 138 (also referred to as a precursor reservoir) can be in fluid communication with at least one of the mouthpiece 133, the one or more chambers (e.g., vapor expansion chambers), and the fluidic channels, to facilitate the triggering of carrierheating and drawing of vapor in response to a user’s creating a suction force (e.g., drawing) on the mouthpiece during use, for example using the draw sensor 123. For example, processor 132 of the cartridge 130 can be configured to activate the heating assembly 134 to heat the carrier in response to the processor 132 receiving a signal from the draw sensor 123 (e.g., via the processor 125 of the vaporizer body 120) indicating that the draw sensor 123 sensed a change of pressure within the device beyond a threshold change in pressure or a drop in pressure within the device below a threshold pressure. Thus, when a user draws on an opening of the mouthpiece 133 causing a change in pressure within the device that is sensed by the draw sensor 123, the processor 132 can activate the heating assembly 134. The information produced by the draw sensor 123 can be recorded over time and stores in memory 142 of the vaporizer device 121. In some embodiments, some or all of the information produced by the draw sensor 123 and stored in memory 142 may be used by ODRA module 204, as described in more detail elsewhere herein.

[0080] The heating assembly 134 includes a heating element and heater control circuitry configured to control the heating element. The heating element can include a coil heater, rod-shaped heater, pancake heater, chemical heater, a ceramic heater, mesh heater, wick and coil, sponge and coil, and / or any other heater that is sized, dimensioned, and constituted of material suitable for heating the carrier material.

[0081] The processor 132 of the cartridge 130 can include one or more of: a general purpose processor, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a controller, a microcontroller, a state machine and so forth. Under some circumstances, a “processor” may refer to an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), etc. The term “processor” may refer to a combination of processing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core or any other such configuration. The processor 125 of the vaporizer device 120 can include one or more of: a general purpose processor, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a controller, a microcontroller, a state machine and so forth. Under some circumstances, a “processor” may refer to an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), etc. The term “processor” may refer to acombination of processing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core or any other such configuration. The processor 132 can be in electronic communication with the memory and can be configured to read information from and / or write information to the memory.

[0082] The power supply 124 of the vaporizer body 120 can include any suitable battery or fuel cell, for example having high-drain characteristics. In some implementations, the vaporizer body 120 can include a mechanical interface (e.g., a button) as part of the I / O 126 that the user can actuate to trigger the heating and vaporization of the carrier. The input / output module 126 can include one or more of: a push-button control for causing vapor generation (as an alternative to activating the heating assembly 134 based on the draw sensor 123), a battery indicator, an electromechanical connector for charging and / or data communication, a light source (e.g., one or more light-emitting diodes), etc. The indicator(s) 128 can include one or more of: an illumination source (e.g., one or more light-emitting diodes), a speaker, a display screen, a vibration component (e.g., a vibration motor or a piezoelectric vibrating element), etc. In some embodiments, one or more of the indicator(s) 128 can be included in or controlled by a component of the input / output module 126. Vaporizer device 120 may also comprise a communication module 141 , which may comprise one or more of a Near Field Communication (NFC) I Dynamic Near Field Communication (DNFC) tags / chips operable to communicate with mobile communication device 110, one or more Radio Frequency Identification (RFID) device operable to communicate with mobile communication device 110, one or more Bluetooth™ modules capable of communicating with mobile communication device 110, and / or one or more suitable, audio, radio or optical communication means operable to communicate with mobile communication device 110.

[0083] In some embodiments, the mobile communication device 110 can communicate with the vaporizer body 120 and / or cartridge 130 by way of one or more of optical communication (e.g., using indicators 128 to transmit information via the camera of mobile communication device 110), static Near Field Communication (static NFC) and / or dynamic Near Field Communication (dynamic NFC).

[0084] With reference to Figure 1 , the operation of the On-Device Risk Assessment module 204 will now be described.

[0085] In some embodiments, the vaporizer device 121 may comprise an On- Device Risk Assessment (ODRA) module 204. Using sensors, memory and processing power on the vaporizer device 121 , it is possible to analyze the use of the vaporizer device 121 to ascertain the risk that a user has changed and needs to be reauthorized via authentication. The output of this analysis can be a risk score (similar to the one described elsewhere herein) and can be used on the vaporizer device 121 to make its own re-locking decisions and / or be transmitted to server 140 (via LED scenarios for the static NFC devices, or via data embedded in the URL for the dynamic NFC devices, as described in more detail elsewhere herein, or through any other suitable data communication means used by communication module 141 ). The basic principle behind on-device risk assessment is similarity. A user’s draw behavior shows certain patterns that can be used to identify a user by constructing a draw and usage pattern signature. Data that can be used by the device for on-device risk assessment include draw data, pod data, and time data. Examples of draw data include, but are not limited to, draw duration and draw intensity (e.g., collected with draw sensor 123). Examples of pod / cartridge data include, but are not limited to, pod / cartridge ID, pod / cartridge Stock Keeping Unit (SKU), pod / cartridge heating configuration, pod / cartridge user counter. Examples of time data include, but are not limited to, timestamps, which can be derived into time of day, day or week, week of year, month of year information, etc. In some embodiments, other sensors may be added to the vaporizer device 121 to generate information that can be used by the ODRA module 204 to perform on-device risk assessment. Examples of such other sensors include, but are not limited to, fingerprint sensors, noise sensors (microphone), light sensors (optical), Photoplethysmography (PPG) sensors for pulse wave analysis, etc.

[0086] Similarity analysis may be conducted on the datasets above so that the ODRA module 204 can derive behavioral patterns from who the user uses the vaporizer device 121 , which is then used as a baseline against new data recorded.

[0087] In one embodiment of the present disclosure, when a user unlocks a new vaporizer device 121 , the device will enter a calibration phase when raw data for the baseline is being recorded and analyzed. This baseline can take the form of simple statistical calculations or advanced analytical models depending on the computational power and memory capacity of the device. However, the core principles of establishing abaseline and then comparing new data against that baseline functions similarly regardless of sophistication. The amount of data necessary for establishing the baseline can also vary depending on the specific data input used and can be configured by the platform.

[0088] As will appreciated, the more data used for the baseline leads to better predictive power, however, more data used also means more time needed before the device enters the next (risk analysis) phase. ODRA module 204 ingests a given amount of device interaction data (defined herein as data generated and stored by the device during regular use, such as in drawing on the device, charging the device, interacting with sensors and I / Os of the device, etc.) to establish a baseline and then uses it to conduct anomaly detection analysis against new data received. In one non-limiting example of this, a particular user’s average draw length may be 3 seconds, fits with a normal distribution curve, and has a standard deviation of 0.2 seconds. This implies that the ODRA module 204 should see only 5% of new draws coming in that are outside the range of 2.6 seconds and 3.4 seconds. If the ODRA module 204 then observes that 20% of new draws are coming in above 4 seconds, that indicates a statistically significant anomaly which leads the ODRA module 204 to raise the user’s on-device risk score.

[0089] The same concept of pattern recognition can be applied to other sources of data. For example, if a user’s draw intensity pattern, as indicated by air flow pressure of draws (as measured by draw sensor 123), changes dramatically from a statistical model of the baseline dataset, risk of dissimilarity goes up and so does the on-device risk score.

[0090] Another example is if a user’s pod SKU ID is relatively stable (indicating that the user always prefers pods of a certain flavor / SKU), and then suddenly changes into another type of flavor / SKU, this can indicate a risk of user change and cause the device to raise the on-device risk score. Information relating to a user’s pod SKU ID (and any other data that may be used by the ODRA module 204) may be stored in memory 142.

[0091] In yet another example, if a user’s typical time of use is in the morning and evening, but the ODRA module 204 receives a sudden change of new data which shows the device is now being used during school hours, this can also trigger an increase in the on-device risk score as the patterns of use have deviated from the baseline.

[0092] Finally, in another example, a user’s biometric data such as fingerprints are recorded and stored on the device during initialization or unlocking of the device. This action may be supervised by a human agent at a POS or digitally supervised usingcomputer vision technologies. The initially recorded fingerprint data is therefore the baseline data used by the device to conduct similarity analysis. In subsequent use of the device, the device may require that the user engages the fingerprint sensor (such as putting their recorded finger on the sensor) from time to time, and through comparison of the new fingerprint data recorded from the sensor against the initial data, the device forms a risk score based on how similar the two data are.

[0093] The on-device risk score is particularly useful if the vaporizer device 121 and I or the server 140 can take access control enforcement actions on it.

[0094] In extreme cases in which the on-device risk score is relatively elevated due to significant and sudden changes in user patterns, the device can override its current unlock conditions and self-lock immediately (or within a shortened amount of time, as compared to when it would have otherwise scheduled a relock). This helps prevent abuse of the platform during the period of time when the device is unlocked, and before the next re-lock event.

[0095] Under normal circumstances, vaporizer device 121 will transmit a device risk object back to server 140 during the next re-lock event, so that server 140 can take the device risk object into account when generating the next unlock sequence.

[0096] The device risk object may include the device determined risk score, and also the input data used by the vaporizer device 121 to determine that risk score. For example, in a draw duration-based similarity analysis on normally distributed duration data, the vaporizer device 121 may conduct the similarity analysis using mean, standard deviation, and quartile ranges of the data set between baseline and recent datasets to compare for similarity. The device risk score may be the weighted average delta between baseline and recent signatures. While the device risk object may include the device risk score, and also include the mean, standard deviation, and quartile ranges of the baseline and recent datasets. This additional data may give the server more context on why the vaporizer device 121 believes a user to be higher or lower risk and can be used by the server to further deduce a user account’s potential exposure to risk.

[0097] For example, the server may see that all other data inputs do not show dissimilar indicators for the user (e.g., same IP address, device has not been reported as being misused, no abnormal transactional behavior, etc.), however, the on-device risk score is elevated to the 80th percentile, where the 100th percentile is the highest risk. Inthis case, the server may decide to use varying verification mechanisms to double check that the unlocking user has not changed despite all other server-side indicators being low risk. Upon reception of a valid verification, the dynamic risk assessment system 200 may amend the server-side risk score and increase it based on the on-device risk score, leading to a shorter duration of time before the next re-lock event.

[0098] User behaviors can change over time naturally. Even draw patterns can change as a user gets more familiar with a new device. This is why it is critical for an on- device similarity analysis relying on baseline data to have a capability to evolve with user behavioral changes. This can be achieved by the ODRA module 204 in a number of ways.

[0099] In one embodiment of the present disclosure, the ODRA module 204 can achieve this by using a baseline reset whenever the device is unlocked. In this case, the device would delete the baseline data from memory when an unlock event occurs and rebuild its baseline model with new data coming from the user after that unlock event. An advantage of this method is that the implementation complexity is fairly low and any changes in user behavior can be captured in the baseline right away. The disadvantage of the method is that a malicious user has an opening to give the device to an unauthorized user right away after unlocking and have the unauthorized use data be recorded as baseline.

[0100] In another embodiment of the present disclosure, the ODRA module 204 can achieve this by permitting gradual evolution of the baseline data calculations and introducing changes to the baseline in a stepwise manner or a gradual manner. Effectively, this creates an evolving baseline that slowly adjusts itself to any changes in user behavior over time. For example, in a situation in which a risk model is based solely on draw duration analysis, the ODRA module 204 may receive a number of draw durations in seconds and finds the mean and standard deviation of the dataset. Thus, if the model uses a 100-draw baseline, this would mean that the first 100 draws by the user after the initial unlock are recorded into this baseline. Then, the model could observe the 101stdraw. If this draw occurs as an outlier per the mean and standard deviation of the baseline, it raises the on-device risk score. If, on the other hand, this 101stdraw occurs within an acceptable probability range (e.g., within 1 standard deviation to the mean, which would be 68%), then the on-device risk score could be reduced.

[0101] In another example, the ODRA module 204 could re-adjust the baseline every 50 draws. Thus, after the 150th draw, the model could add the new 50 draws into the mean and standard deviation calculations of the original 100 draws. And if there are significant differences between the first 100 draws and the last 50 draws, those differences would be applied to the mean and standard deviation reference for the next 50 draws.

[0102] In this manner, the baseline (and therefore the mean and standard deviation of expected draw lengths) on the device will continuously change based on the user’s new data.

[0103] To prevent the ODRA module 204 from drastically changing its baseline to adapt to any new users (including ones which are not the expected user), a maximum change to key variables can be applied so that data showing differences beyond a predetermined threshold from the baseline will be discarded rather than integrated.

[0104] In the case above, this can be done by discarding all draw lengths which fall beyond two standard deviations of the mean from baseline. Where the distance from mean can be configurable by the platform to find the best way to preserve the integrity of the baseline while accounting for natural user behavioral changes over time.

[0105] With reference to Figure 2, operation of the dynamic risk assessment system 200 will now be described.

[0106] As shown in the exemplary embodiment of Figure 2, disclosed herein is a dynamic risk assessment system 200 in which products are linked to a user ID and where each user ID has an associated risk profile that is evaluated by risk engine 209 which takes into account a variety of data inputs 207 from a variety of input sources 206, such as user characteristics 201 , transaction information 202, web session metadata 203, information relating to the mobile communication device 110 (including, for example, OS type and version, browser type and version, any device IDs, and location data) and on- device risk assessment module 204 outputs (as described in more detail elsewhere herein). Examples information includes, but is not limited to, draw frequency, individual lengths of draw and pauses between draws. It may also include draw intensity data and it may be combined with the consumable data (e.g., SKU, SKU characteristics, SKU vapor production rate, heating algorithm and constituents, etc.). As will be appreciated by the skilled reader, other input sources 205 may be possible including, but not limited to drawdata (e.g., on / off time stamps, additionally draw intensity overlaid over draw on / off timestamps), consumable SKU data (e.g., SKU, serial number, content composition, manufacturing date, purchase date, draw count of consumable), charging data (e.g., frequency, duration, intervals, charger type), feedback data sources 214, mobile communication device 110 information (e.g., device identification such as UID, type and version, OS type and version, browser type and version, IP address, MAC address, phone number, session meta data, location data and / or estimated location data - using IP and connectivity), Point of Sale (POS) information (e.g., including location, attempted purchases, successful purchases, timestamp, frequency and quantity of transactions for each SKU).

[0107] In some embodiments, other consumables may form part of the platform. Such consumables may, for example, include packages of snus or packs of cigarettes. In such embodiments, the platform cannot provide ongoing access control to such consumables, but provides access control only at POS. The risk scores as described here may however affect access at POS, and the usage and purchase behavior with these types of consumer may affect the risk score for the connected devices and consumables.

[0108] In some embodiments, the packages of the consumables may include a printed or deposited antenna array, such that the array acts to absorb surrounding radio waves to energy harvest. Then, the consumables may broadcast their identities on a frequency such as 2.4 - 2.5Ghz. Alternatively, or additionally, the antenna array of the consumables may be powered by a thin film battery. The circuit may include a modulation circuit, such that a Bluetooth receiver may recognize the broadcast according to Bluetooth protocol and identify the consumable. The broadcast may then be discoverable by any Bluetooth receiver, such as a mobile phone running one of the applications described herein. This allows analog consumable packages to be discoverable by the anti-hub applications described herein.

[0109] In addition, the risk engine 209 may also take into account feedback data sources 214, such as information from other users (submitted via, for example, a mobile phone app) relating to suspected malicious or identified underage use (e.g., signaling of a vaporizer found in a given geolocation corresponding to a school or a country or state where said product is illegal) which would ultimately increase the risk profile associated with a given user ID.

[0110] One non-limiting example of a feedback data source 214 is an anti-hub application (or a device serving such an application) to be used in environments where underage users are present, such as schools. When present at a qualified high risk environment (such as a school) the anti-hub application (running, for example, on a smart phone or other mobile communication device) sends and receives signals on Bluetooth or other near to mid radio frequencies or protocols, and the drug delivery device (e.g., vaporizer device 121) sends and receives signals on Bluetooth or other near to mid radio frequencies, each identifying themselves to the other, without the necessity of pairing. The anti-hub application then reports the presence of the drug delivery device in the context and location of a restricted location (such as a school), informing the platform 100 and letting the platform 100 determine the original source of device risk associated. The drug delivery device may note the presence of the anti-hub application and adjust the on- device risk assessment (via the ODRA module 204) and the possible re-lock frequency recourse.

[0111] Based on the output of the risk engine 209, a given user will be prompted (with varying levels of onerousness) to perform user age authentication such as One-Time Password (OTP), Personal Identification Number (PIN), ID document / likeness checks (e.g., driver's license, passport) and on a frequency that is dependent on their risk score. In some embodiments, risk scores may initially be set to a particular level for all new user IDs, or all new user IDs with a particular user characteristic, such as age, location, etc. In some embodiments, as the risk engine 209 gathers increasing amounts of data on an ongoing basis, the risk score for a given user ID may continuously be assessed and updated, as described elsewhere herein.

[0112] In some embodiments, the outputs of risk engine 209 are provided to risk adjusted authentication module 212 to determine whether user authentication is required, as described in more detail elsewhere herein. In some embodiments, the outputs of risk engine 209 are provided to risk profile management module 213 to update a user’s risk score based on the output. The updated risk score may then be used to adjust the access control of the user by the risk-adjusted access control module 215 and / or provide information to the risk adjusted authentication module 212 to authenticate a user.

[0113] The risk engine 209 relies on several categories of input data, assesses risk from that data, and outputs actionable risk assessment information as an output. In someembodiments, the risk engine 209 is operable to determine the probability of a certain event or condition of use leading to the violation of platform policies.

[0114] In some embodiments, the risk engine 209 is operable to assess, during platform access events (such as unlocking a device or making a purchase), how likely is it that permitting that event will lead to a controlled product being exposed or consumed by underage users. The risk engine 209 can make this assessment based on both intrinsic and behavioral risk of a user. Input sources 206 can be expanded or removed over time as the platform 200 matures in inferring which data inputs (aka risk indicators) are more relevant than others, and capabilities of the platform advance (such as new data captures introduced into a user’s interaction with the platform).

[0115] As used herein, the term “intrinsic risks” are risks associated with known characteristics of a user (i.e., referred to herein as “intrinsic information”), obtained throughout their interaction with the platform. Examples of data inputs 207 associated with known characteristics of a user include, but are not limited to, user photo ID information, user name, user age, user gender, user birthdate, user address, user ID expiry date, user account information, user phone number, user email address, user delivery information, user delivery address, user delivery phone number / email address, user payment information, name of cardholder, user payment card type, user payment card ending digits, user payment card expiry date, user payment Card Verification Code (CVC), user mobile device information I digital metadata signature, user mobile device model, user mobile device operating system (OS), user mobile device browser, and / or user mobile device browser version.

[0116] In some embodiments, in assessing intrinsic risk, risk engine 209 may evaluate risk based on irregularity heuristics (such as in the case of an expert system) or using more advanced analytics I machine learning techniques (such as clustering techniques).

[0117] Examples of irregularity heuristics include, but are not limited to, a mismatch between delivery address and photo ID address, a mismatch between delivery phone number and account phone number, a mismatch between payment cardholder name and name of the user, and an unlikely mismatch between the version and type of operating system and browser (e.g., a user authenticates with later version of the same OS and browser, followed by an earlier version of OS and / or browser). Examples of clusteringtechniques include, but are not limited to, clustering techniques are applied to a dataset of users with violations or excessive risky behavior (such as having their devices being detected near schools or being reported by teachers I parents) and certain user characteristics are seen to be commonly found among at-risk users. This exemplary analysis may lead to the following risk assessment rules: a user is determined to be of a higher risk category if their age is under 30, a user is determined to be of a higher risk category if their ZIP code is 90210 (or among a list of high risk ZIP codes), a user is determined to be of a higher risk category if phone number is within a high risk area code.

[0118] As used herein, the term “behavioral risk” are risks that are based on actions taken by a user (referred to herein as “behavioral information”). For example, the platform 100 can track the following actions and use the outcome of such actions as data inputs 207: vaporizer device actions, vaporizer device reporting and implied behaviors, as described in more detail elsewhere herein.

[0119] In some embodiments, both heuristics and machine learning enabled analytics may be used to assess anomalies in these actions and determine whether the user is engaging in risky behaviors. Some examples of risky behavior that would lead to a higher risk score for a user include, but are not limited to, a user account has attempted to unlock many devices within a short period of time (such as 5 devices within 15 minutes), a device unlocked by a user has been reported by another user or a third party as being seen at a school, but not registered to an educator, a user account has attempted to purchase a significant number of pods from multiple retail points (such as an excessive example of 80 pods purchased within 24 hours across 8 stores).

[0120] In some embodiments, risky behaviors generally take the form of unusual patterns of behavior for personal use of a vaporizer device, and I or actions that cause the platform to infer that the user of a vaporizer device has changed. This concept of similarity analysis may be applied throughout the risk assessment process.

[0121] In some embodiments, given that a vaporizer device is strictly intended for use by a registered user, whenever the platform infers that the user of a vaporizer device has potentially changed from the registered / authenticated user, the risk profile associated with that registered user will show an increase in risk.

[0122] In some embodiments, similarity analysis can first be applied whenever there is an interaction between a user and the server 140. This occurs at differentmoments throughout platform use, such as, for example, during account creation, device unlocking, e-commerce order placement and tracking, etc. As will be appreciated by the skilled reader, interaction between a user and the server can be provided by a web app located on the mobile communication device 110, or any other suitable device.

[0123] In every interaction with server 140 (including the initial ones), server 140 will store all web session metadata 203 associated with the interaction via the API calls made to server 140 by the web app on mobile communication device 110. Authenticated web sessions (user interactions with server 140 via a web app) can produce a large amount of web session metadata 203. Examples of such metadata include, but are not limited to, device information, such as device type (e.g., mobile, tablet, desktop), screen resolution, OS and version, browser information, such as browser type and version, supported web standards (such as HTML5, CSS3 features), browser language and preference settings, network information, such as a user’s IP address, connection type (e.g., Wi-Fi, cellular) and approximate geographic location (based on IP address or more precise location if associated permissions are granted by a user). By capturing such metadata generated by interactions with the platform 100, a user’s digital signature may build over time as interactions with server 140 grow.

[0124] For example, for an average user, it may be that the user generally accesses server 140 from 3 to 4 known IP addresses (e.g., home, office, one or two are mobile data), and that all known IP addresses are tied to physical addresses proximate the user’s delivery address. Fora recent online purchase of pods (i.e., cartridges), however, the user may have added products to their cart that they do not usually use (for example, menthol flavored pods whereas they might usually use non-menthol tobacco flavors) with a quantity of pods that is significantly above their usual cart size, and the order placement is coming from an IP address originating from another location far away from their delivery address with device OS and browser versions that do not logically follow previous access attempts.

[0125] Due to the dissimilar nature of the above-described purchase characteristics, both digital and behavioral, the risk engine 209 would produce an output that would increase the risk of the user risk profile. Such increased risk profile could be communicated to the POS (via risk-adjusted transaction authorization module 216), which could result in the transaction being either blocked, or being contingent on the purchaserbeing subject to authentication mechanisms, through varying recourse actions, such as facial likeness to user ID picture, verification they are using the same phone as the original registration, etc. Inability of the purchaser to authenticate could result in denial to purchase, and a red flag on the account preventing purchases elsewhere.

[0126] In some embodiments, the output of the risk engine 209 can be a risk score associated with a user. A user’s risk score can enable vaporizer devices 121 and POS devices 180 to assess the riskiness of a requested access to violate platform policies. As will be appreciated by the skilled reader, a user’s risk score can take many forms depending on the use case. For device unlocking, for example, a user’s risk score can be within a predetermined set of values that the vaporizer device 121 is able to interpret and apply the corresponding risk mitigation actions (such as relocking within a short period of time for higher risk scores, and relocking within a long period of time for lower risk scores). For POS purchases, for example, the user’s risk score may be expressed as any range of values that the POS device 180 can interpret and then apply the corresponding risk mitigation actions (such as requiring additional verification steps, limiting the number of units of a product that can be purchased or rejecting the transaction altogether).

[0127] In some embodiments, the platform is operable to carry out the following risk-adjusted methods. When a platform event occurs, the event may lead to the creation of behavioral information and / or web session metadata and / or information being generated by the on-device risk assessment module 204 and / or transaction information 202. That information is combined with user characteristics 201 and input into dynamic risk assessment system 200 as data inputs 207.

[0128] Some or all of these data are interpreted by one or more suitable data interpreters 208 in order to ensure that the data is usable by the predictive model(s) 210 of risk engine 209. The output of the risk engine 209 is fed into risk profile management module 213 and used to determine whether a risk score of a user should be increased, decreased or maintained. In some embodiments, the risk profile management module 213 can do this by taking into account the outputs of the risk engine 209, as well as one or more prior values of the user’s risk score (referred to herein as the user’s risk profile). Once the determination is made, a user’s updated risk score is used, along with other data (such as transaction authorization request data, for example) in some circumstances,by one or more of the risk-adjusted authentication module 212, the risk-adjusted access control module 215, and the risk-adjusted transaction authorization module 216.

[0129] As is described in more detail elsewhere herein, those modules then use that information to, for example, send an authentication request (having a particular level, as described elsewhere herein), modify an authentication level, control access to a vaporizer device, or authorize / decline a transaction, or any combination thereof (such as, for example, the declining a transaction pending the outcome of an authentication request having a modified level).

[0130] With reference to Figure 3, operation of the risk-adjusted authentication module 212 will now be described. The present disclosure also relates to a risk-adjusted authentication module 212 which carries out multi-leveled risk-adjusted authentication methods. As defined herein, “authentication methods” are methods that aim to determine whether a user is the user registered to a device. Such methods can be used by the platform to mitigate certain risk indicators assessed by risk engine 209 to prevent unauthorized access (e.g., underage use, or use by bad actor adults enabling underage use).

[0131] The general principle of the multi-leveled risk-adjusted authentication methods is to increase the amount of friction to a user’s interactions with the platform as the perceived risk associated with that user increases, as having more verification steps for higher risk users inherently discourages risky behavior. Each level will therefore provide a different level of security, and a corresponding level of difficulty / onerousness for the user (also referred to herein as user “friction”).

[0132] In one exemplary embodiment, a risk-adjusted authentication method includes four sperate levels of verification. As will be appreciated by the skilled reader, however, other numbers of levels and other verification methods, schemes and technical means can be used. In the one exemplary embodiment, the first level relates to a method by which verification is done via a personal identification number (PIN) or secret. The method involves ensuring that a user requesting access possesses a piece of information that only the registered user should know. This level is relatively quick and represents a light burden on the user. This level does not however provide a high degree of reliability, as a PIN or secret can be communicated from a registered user to another person.

[0133] In the exemplary embodiment, the second level relates to a method by which verification is done via one-time password (OTP) sent to mobile communication device 110 via, for example, text message. The method involves ensuring that a user requesting access action is in possession of the mobile communication device 110 owned by the registered user. This second level is not as quick as the first level, but also represents a relatively light burden on the user. This second level does however provide a higher degree of reliability than the first level, as a malicious actor would need to give their phone, access to their phone, send over a text message, or register their account with an underage user’s phone number.

[0134] In the exemplary embodiment, the third level relates to a method by which verification is done via biometric authentication via the mobile communication device 110. The method involves ensuring that a user requesting access is biometrically the same as the registered user. This third level is slower than the second level, and also represents a relatively higher burden on the user than the second level. This third level does however provide a higher degree of reliability than the first level, as a malicious actor would need to be present when an underage user (for example) is executing the access action (unlock or purchase).

[0135] Finally, in the exemplary embodiment, the fourth level relates to a method by which verification is done using a full identification (ID) document check via mobile communication device 110 (including a biometric check against the ID check). The method involves ensuring that a user requesting access action is in possession of documents (e.g. driver license, passport) that proves their identity and intrinsic characteristics (especially age). This final level is much slower than the third level, and also represents a very high burden on the user. This fourth level does however provide a very high degree of reliability, as a malicious actor would need to provide their identity document to the underage user. In practice, this level of checks would almost never be done without liveness checks (also known as liveness detection), significantly increasing friction for malicious actors.

[0136] With reference to Figure 3, in some embodiments, the risk-adjusted authentication module 212 proceed as follows. At step 301 , system receives an updated risk score from the dynamic risk assessment system 200, together with request information. As used herein, request information relates to any information relating to auser request, such as, but not limited to, unlocking a vaporizer device, unlocking a cartridge, purchasing a product, etc. The risk-adjusted authentication module 212 then sets an authentication level based on the updated risk score, and (optionally) the request information, at step 302. Then, at step 303, an authentication request (having the set authentication level) is sent to the user. Finally, at step 304, the user authentication result information (e.g., the user has been successfully authenticated or the user has not been successfully authenticated) is fed back to the dynamic risk assessment system 200 for calculation of the risk score and potential further action (e.g., increase of the risk score by the dynamic risk assessment system 200 and use of the increased / decrease the user’s risk score by the risk-adjusted access control module 215 to further control - or remove controls - to a vaporizer device).

[0137] In a first example of the operation of risk-adjusted authentication module 212, a user may have, for example, requested that the server 140 unlock their vaporizer device. The IP address (as part of the web session metadata) associated with the mobile communication device 110 being used by the user to make the request is associated with a country in which the user has not yet made a request. This could, for example, indicate that the user’s account access has been compromised by a malicious actor. In such a case, the risk-adjusted authentication methods 212 may trigger an appropriate (i.e., having a level set based on an adjusted risk score) authentication request to the user prior to proceeding with the unlock access action using the risk-adjusted transaction access control method 215. Once the user completes an OTP or PIN input, the user would be permitted to unlock that device. Once the user is authenticated, the user’s risk score is released to risk-adjusted access control module 215 and / or risk-adjusted transaction authorization module 216. As such, authentication may not change the user’s risk score, since the authentication action only ensures that the user is the one that the platform 100 has on file and may not change the risk score associated with that user.

[0138] In a second example of the operation of risk-adjusted authentication module 212, a user may have requested to make a purchase at a physical POS in a location that does not seem to be likely (e.g., a situation having a low likelihood of occurring based on one or more of predictive models 201 ). For example, the user may have made a purchase at a POS in New York, and then eight hours later, the user’s account may have been used to make another purchase at a POS in Los Angeles. Since it is unlikely (but notimpossible) that a user has traveled from New York to Los Angeles within that time span, the predictive models 210 can compute a non-negligible likelihood that the user’s account access has been compromised. As will be appreciated by the skilled reader, were these transactions to have occurred one hour apart, the risk engine 209 would have inferred a significantly higher likelihood of the user’s account access having been compromised and the risk-adjusted transaction authorization module 216 would likely recommend declining the second transaction.

[0139] In the case of the eight-hour time span, the dynamic risk assessment system 200 and the risk-adjusted transaction authorization module 216 may only allow this transaction to occur after a third level authentication, as described above. For example, the user’s registered mobile communication device 110 could be sent a Uniform Resource Locator (URL) via text message, which URL would instruct and permit the user to submit their likeness video at the POS, and once the likeness is received and verified against the ID on file, the location of their IP for uploading the selfie is recognized to be in LA, then their transaction would be permitted.

[0140] In a third example of the operation of the risk-adjusted authentication module 212, a user has requested to unlock their device, but the device has been reported in a nearby school. Such a report may be performed by way of a feedback data sources 214, as described in more detail elsewhere herein. In such a case, the user would be required to undergo, for example, a fourth level authentication, as described elsewhere herein.

[0141] In order to exchange data between products and the server 140, the platform 100 relies on varying levels of connectivity from device products (such as vaporizer devices 120 and cartridges 130) and other non-device products sold. Nonlimiting examples of non-device products include packages of edible I oral drugs, smokable consumables, inhalable consumables to be used in conjunction with heated tobacco devices, or any consumable that does not require a connected device to be served (patches, gum, injections whether syringe type or dosed injector pen), nasal delivery instruments, inhalers, etc. Indeed, some products may have full connectivity, for instance having connectivity including one or more of, but not limited to, Bluetooth, Wifi, Zigbee, proprietary radio, WAN, LoRa etc., and others may rely on limited connectivity capabilities, for instance dynamic or static NFC. The platform may include multiple typesof connectivity type products, each contributing a subset of risk data to the overall assessment. Each of the different levels of connectivity type products may co-exist in the system, from products that are not connected ever, to products that occasionally connect, to products that are ever-connected. In all cases, the general mechanism used to provide access control to devices is as follows.

[0142] With reference to Figure 4, a method orchestrated by the risk-adjusted access control module 216 will now be described. The method starts when a user wishes to unlock a vaporizer device for use. The platform requires a unique device identification (device_uid) associated with the device, along with the value of a dynamic challenge generated by the device (dynamic_value). As described in more detail elsewhere herein, these values can be provided to the platform 100 in a number of different ways. At step 401 , the mobile communication device 110 used by a user receives the device’s unique ID and the dynamic challenge and sends this information to the server 140.

[0143] It should be noted that at step 401 , one method of achieving the device's unique ID and the dynamic challenge can be to display a sequence of color patterns that encode the data (via colors or blinks or animated other behavior) using the device's LED display or other display types and having a camera module on the mobile communication device to interpret the recorded LED display sequence via computer vision.

[0144] Then, at step 402, the server looks up the secret encryption key associated with the device using the device’s unique ID. The server also receives an indication of the current risk score associated with the user from the dynamic risk assessment system 200 at step 403. Using the dynamic challenge, the secret encryption key associated with the device and the current risk score associated with the user, the risk-adjusted access control module 215 generates an unlock sequence at step 404. Finally, at step 405, the unlock sequence is sent to the mobile communication device 110.

[0145] Once received by the mobile communication device 110 and displayed to the user, the user can then use input means on the vaporizer device (such as any means forming part of I / O module 126) to input the unlock sequence. By using this method, as is described in more detail elsewhere herein, the platform 100 can provide risk-adjusted access control to a device that is not necessarily equipped to receive risk-associated information from a dynamic risk assessment system 200. In some embodiments, the inputmeans may be a push button switch, or any other suitable sensor, such as a capacitive sensor.

[0146] In some embodiments, step 401 can be achieved by way of a static NFC tag associated with the device and NFC scanning technology on mobile communication device 110. This NFC tag may contain a URL such as www.platform.com / unlock / fdevice_uid}, where device_uid is the unique ID of the device, which could be provided by the server during manufacturing. This URL is tapped on by the user (using a web-based application running on the mobile communication device 110) once scanned by the mobile communication device 110, which then opens a browser on the mobile communication device 110 and is connected to the server via a web app associated with the URL.

[0147] A dynamic unlock challenge (dynamic_value) is generated by the vaporizer device (by for example processor 125) and also transmitted to server 140 (e.g., input to the mobile communication device 110 using the web app interface or automatically using a camera module of mobile communication device 110 and computer vision). As will be described in more detail elsewhere herein, the dynamic unlock challenge could alternatively be input to the mobile communication device 110 directly using dynamic NFC technology.

[0148] Then, the server uses the dynamic_value and a device secret key (device_secret_key) associated with the device_uid to produce the unlock sequence and sends it to the mobile communication device 110, along with an indication of the risk score associated with the user.

[0149] In some embodiments, server 140 can access a database 180 containing linked entries of all device_uids with their associated device_secret_keys. The vaporizer device may also have an on-device memory where it stores its own device_secret_key. In some embodiments, all device_uid and device_secret_keys are uniquely paired and randomized so that device_secret_keys are not derived from device_uids, and vice versa.

[0150] Then, the mobile communication device 110 displays the unlock sequence to the user such that the user can input the values into the device. Once the device receives the unlock sequence, it then interprets the unlocking sequence via the device unlock function described in more detail elsewhere herein. As will be appreciated by the skilled reader, the vaporizer device 121 can receive the unlock sequence in a variety ofways. In the case where devices do not have Bluetooth connectivity, the sequence can be input into the device by the user via instructions visible from a mobile device. This can be done via buttons or via device events such as pod / cartridge insertion events (e.g., 3 insertions = numerical value 3). As will also be understood by the skilled reader, the unlock sequence can be received by the vaporizer device 121 by any means at the disposal of I / O module 126.

[0151] As described in more detail elsewhere herein, the unlock sequence may consist of a first part based on the device_secret_key and dynamic_value and a second part based on the risk score, which second part may be used by the vaporizer device to determine when the next device lock should occur. As will be appreciated by the skilled reader, the first and second parts need not be in a particular order, nor do they need to be sequential. For example, digits of the first and second parts may be interleaved.

[0152] With reference to Figure 5 and Figure 6, detailed embodiments of methods carried out and orchestrated by the risk-adjusted access control module 215 will now be described. In the following description, it is assumed that the user has created their age- verified account (i.e. , the user is registered with the platform 100 and age-verification has been successfully performed).

[0153] In some embodiments, user registration may comprise a user entering their name and email address (followed by email verification) into, for example, a website through which the user is trying to make a purchase.

[0154] Once a user is registered on the platform, age verification is performed. In some embodiments, this step may be triggered when a user attempts to purchase an age restricted product (e.g., online) or when the user attempts to activate a new device and has not recently gone through an age verification process. In some embodiments, age verification may also be performed during a device unlock (e.g. when a user’s risk score is higher than a certain threshold, as described in more detail herein).

[0155] When the age verification process is completed, a user can complete their purchase or have their device ask for the secret code necessary to unlock their device, as described in more detail elsewhere herein. In some embodiments, activation of a device is performed only once. Once activated, a device may be locked and unlocked, as also described in more detail elsewhere herein.

[0156] In general terms, a device activation or website purchase event may typically involve the following steps when a user has not undergone age verification relatively recently. First, a user may sign up through third-party authentication (e.g. via a social media account) or via email / password (user registration). Next, the user’s email address may be verified by way of a one-time password. Finally, age verification may be performed.

[0157] In some embodiments, age verification may be performed using known liveness check tools and age estimation tools. In some embodiments, if the age estimation tool returns a result which is too close to a restricted age category, a further step of requesting an image of a government-issued identity card may be performed. If the date of birth on the government-issued identify card is acceptable and the photo on the government-issued identity card matches the image of the liveness check, the platform may consider the user age verified.

[0158] The vaporizer device is locked and the user taps the NFC tag-containing vaporizer device 121 with their mobile communication device 110. When the user taps the NFC tag, the mobile communication device 110 is taken to a web app associated with the platform, where the user logs into their account (if not already logged in).

[0159] This login event may be examined by the platform 100 for irregularities in, for example, web session metadata 203, and a determination is made on whether or not additional verification steps are needed before this particular user can proceed with device unlock.

[0160] Device unlock (i.e. , device access control) starts with the user’s tap on the NFC tag. In some embodiments, the NFC tag may contain a URL such as www.platform.com / unlock / ldevice_uid}, where device_uid is the unique identifier of the vaporizer device and may contain the serial number and information on firmware version, device version and manufacturing date / batch details.

[0161] This URL then opens a browser on the mobile communication device 110, which is connected to server 140 via, for example, a web app associated with the URL.

[0162] In some embodiments in which dynamic NFC technology is used (see Figure 6, step 601), included in the URL may be data that contains device_uid, as well as the dynamic unlock challenge in the form of a string or a value that can be comprised ofnumbers or characters (e.g., dynamic_value). The dynamic unlock challenge may be randomly and uniquely generated on the device using a RNG (random number generator) and may be used by server 140 as a necessary input to generate the unlock sequence.

[0163] In the case of static NFC devices, as shown in Figure 5, the dynamic value may be communicated to the user using other interfaces (step 503), and then the user inputs it to the server while interacting with the web app (or recognized by a camera on the mobile communications device via a camera and computer vision).

[0164] In the case of dynamic NFC compatible devices, as shown in Figure 6, the dynamic value may be included in the URL (step 601 ).

[0165] For example, in a static NFC compatible vaporizer device 121 with four LEDs forming the indicators 128, the device may turn on LEDs in specific positions as a method of communicating this value to the user. In such a case, there are 4 (single LED on) + 3 (2 LEDs on) + 2 (3 LEDs on) + 1 (4 LEDs on) = 10 possible permutations and therefore 10 possible dynamic values that can be sent to the server when the user selects which LEDs are on during the unlock event. The number of LEDs can be arbitrarily large, the method of display can also be with other displays or I / O mechanisms such as vibration motor or any combination thereof.

[0166] In other examples of static NFC compatible vaporizer devices 121 , there may be other methods of transmitting this sequence to server 140 without the user’s involvement as well. For example, the device may play a sequence of LED behaviors (or any other suitable visual display) that can be recorded by a camera function on the web app running on the mobile communication device 110. The web app can then interpret the LED behavior seen on vaporizer device 121 to understand it as a dynamic value sequence, and then provide the appropriate unlock code to the user.

[0167] In any embodiment, and in addition to the dynamic value, device risk objects (along with device risk scores) generated by the ODRA module 204 may be included in the same process, as part of the dynamic value or additional to the dynamic value, as shown for example in steps 520 and 521 of Figure 5. As will be appreciated by the skilled reader, a device risk object may also be communicated to the mobile communication device 110 and server 140 as part of steps 601 and 602, respectively, in accordance with the embodiments shown in Figure 6.

[0168] The dynamic_value may be generated by the vaporizer device per unlock event and may be re-generated after each successful unlock event. This randomizes the unlock sequence between unlocks to prevent users from memorizing a single unlock sequence and repeating unlocking with the same sequence. In some embodiments of the present disclosure, the information transmitted by the dynamic NFC can also include information relating to on-device risk assessment (described in more detail elsewhere herein) that is indicative of an assessment of on-device behaviors and patterns, and the likelihood that the user has changed.

[0169] In some embodiments, a camera function in the web app may employ computer vision techniques to deconstruct images into pixels of RGB values over time at a specified frame rate (such as 30fps, meaning 30 images are captured per second). An example of this data per pixel can be in the format of (r, g, b) where r, g, b represent red, green, and blue values between 1-255. In this encoding, black is represented by the absence of RGB values (0, 0, 0) and white is represented by the full presence of RGB values (255, 255, 255). All other colors on the visible spectrum are represented by values in between.

[0170] A single image may can range from as low as 50x50p to > 1000x1000 pixels. In the case of a given image size such as 240x240p, a total of 57,600 pixels are recorded and parsed by the computer vision function per frame, and 30 frames are captured per second. Each pixel is assigned a color matrix value of (r, g, b).

[0171] From this raw data set, the camera function may then first identify which pixels are relevant to the visual display from the device based on their respective (r, g ,b) values, and may parse the color data per cluster of pixel to derive a series of RGB encoded data communicated over time. Once transmission is completed, the web app may decode the sequence of RGB values transmitted over time into the expect transmission payload (aka device_uid, dynamic_value, device_risk_score).

[0172] In some embodiments using static NFC, the platform 100 could use the LEDs (or other visual display) to communicate the on-device risk score. Either by a user reading the LED positions (unified with dynamic value) or separately, or embedded in the LED code relayed to a camera.

[0173] With reference to Figure 5, for embodiments in which static NFC is used, a user may be prompted to wake up the vaporizer device, by either inserting theconsumable (e.g., cartridge 130) or following an input direction such as long pressing a button.

[0174] A dynamic unlock challenge is generated by the vaporizer device and the device indicators 128 (e.g., light emitting diodes, LEDs) may display a specific pattern (for example only LED #2 might be on) indicative of the dynamic_value. The dynamic_value serves to mathematically create the correct unlock values and their position, which the user must then input into the web app interface of the mobile communication device 110 (step 503). This can be done by the user, manually, or, in some embodiments, automatically using the camera of the mobile communication device 110. In some embodiments, a second step may follow where the device indicators 128 then display a second combination, to communicate one or more device assessed risk values generated by ODRA module 204.

[0175] With reference to Figure 6, for embodiments in which dynamic NFC is used, tapping the dynamic NFC, will wake up the device and place it in “ready for activation mode”. In some embodiments using dynamic NFC, any event, such as consumable insertion, opening of the consumable door (in case of heated tobacco (HT) devices), attempt at drawing or NFC tap would result in device being locked and place in “ready for activation mode".

[0176] Then, device_uid, dynamic value, and any device risk level value generated by the ODRA module 204 may be included in the URL string, along with a current timestamp of the vaporizer device (step 601). These values may be encrypted during transmission either symmetrically or asymmetrically. Some embodiments may forgo encryption and transmit these values in plain text to reduce hardware load and rely on the security provided by the secret key during this data exchange.

[0177] Then, at step 603, server 140 queries database 180 to retrieve (step 604) the device_secret_key associated with the device_uid. In some embodiments, database 180 may form part of server 140. The vaporizer device comprises a memory on-device where it stores its own device_secret_key. All device_uid and device_secret_keys are uniquely paired and randomized.

[0178] Then, server 140 sends the user ID associated with the device_uid to the dynamic risk assessment system 200 (step 605) to retrieve information relating to the user’s risk score (i.e. , risk_score_value at step 606). The server then generates an unlocksequence, as described in more detail elsewhere herein, before sending it to the mobile communication device 110.

[0179] A more detailed description of access control methods in accordance with the present disclosure will now be described with reference to Figure 5 and Figure 6. When a device enters the “locked” state, it will establish its own expected unlock sequence, which is randomly and uniquely generated based on its device secret key and dynamic value. A “locked” state can be defined as a state in which vaporization functions are inoperable, while other functions such as charging may still be functional. A device may enter a “locked” state from the factory or from its own “relock” configurations.

[0180] The unlock sequence is intended to be input into the vaporizer device 121 by the user via one or more interaction modes that interact with the vaporizer device 121 including, but not limited to, button presses (1 or more buttons), charging cable insertions and removals, pod insertions and removals, blowing into the device (triggering the device’s airflow sensors), shaking or rotating the device (triggering signals to the device’s accelerometers and / or gyroscopes), tapping, pressing or sliding on a conductive sensor, pressure sensor or a combination of any of the above, etc.

[0181] In some embodiments, the unlock sequence may be a short sequence of low value digits in order to minimize friction during the user’s physical interaction with the vaporizer device 121. In some embodiments, the unlock sequence may be 4 values long each with values ranging from 1 to 5. It will however be appreciated by the skilled reader that any arbitrary number of values and value ranges can be used, and any permutations of the available interaction modes can be used to input values of the unlock sequence into the device. In one example, a user could press a single button three times, then two times, then five times, then two times (where each cluster of presses could be separated by a specific time period) in order to input the values “3”, “2”, “5”, and “2” into the vaporizer device 121. In accordance with a more complex example, a user could press a button three times, blow into the device twice, insert and remove the charging cable five times, and shake the device twice in order to input the values “3”, “2”, “5”, and “2” into the vaporizer device 121. As will be appreciated by the skilled reader, similar effects could be achieved by having multiple buttons (2 or more) or by introducing variants of interaction, such as short and long presses on a button, or swipes up or swipes down on a conductive input sensor.

[0182] In accordance with some embodiments of the present disclosure, the unlock sequence may comprise two main parts. The first main part of the code is the authentication password.

[0183] Authentication Password = f (device _secret_key, dynamic _value)

[0184] As used herein, the expression “authentication password” means a password which is used only once. The authentication password may alternatively be referred to as an authentication token. In some embodiments, the authentication password is then transformed into a human-readable sequence that can be input by a user as described elsewhere herein (e.g., to make it feasible for a button press to communicate the values). This can be done using another function (i.e., the unlock sequence generation function) that transforms the output of the raw authentication password into values in base x (x = 5 for the example, here), and truncates the string into three digits.

[0185] The first part of the unlock sequence is also calculated by the vaporizer device 121 on its own whenever it enters the “locked” state. The dynamic_value will be randomized by the vaporizer device 121 whenever a successful unlock attempt is made. Accordingly, the vaporizer device’s 121 unlock sequence will change semi-randomly based on the dynamic_value component.

[0186] In some embodiments of the present disclosure, the second part of the unlock sequence may be an encoded risk score computed by the server based on a raw risk score (risk_score_value) received from the dynamic risk assessment system 200.

[0187] In one example, the raw risk score may be a single digit having a value between 1 and 5. Before communicating the 5-digits of the unlock sequence to the user via the web app (for example), server 140 first appends the risk score digit to the 3-digit authentication password described above, forming a 4-digit code. Then, in some embodiments, the server may apply a transformation to the 4th digit (the raw risk score) so that the 4th digit can be derived as a function of the first 3 digits and the risk score digit. A simple example of such a function could be a simple mathematical operation such as summation. For example:

[0188] If f(x) = sum(x), the first 3 digits are of values, 3, 2, 4, and the risk score is4.

[0189] Then sum(3, 2, 4, 4) gives 13. 13 in base 5 is expressed as 23. Thus, the digits 2 and 3 are appended to the initial 3 digits and forms the unlock code of 3, 2, 4, 2, 3. Then, when the vaporizer device 121 receives the code 3, 2, 4, 2, 3, (step 510 / 608), it first verifies that 3, 2, 4 is the correct authentication password. Then, it may calculate the raw risk score value from the final 2 digits of 3 by interpreting the base 5 encoding of the values, reverting the summation function. In this example, a raw risk score of 4 would be found.

[0190] This encoding applied to the raw risk score ensures that even if a user’s raw risk score is constant over time, the expression of the raw risk score when instructed to input it into the device will be dynamic, driven by the dynamic_value generated by the device to initiate the unlock.

[0191] As step 607, the server 140 sends the unlock sequence to the mobile communication device 110 via the web app with instructions to the user on how to input this sequence to the vaporizer device 121 .

[0192] In some embodiments, vaporizer device 121 is programmed with anti-brute force measures, such as that if the user keeps attempting the wrong combination, the device will lock out for increasing periods of time, making it impractical to guess the combination (i.e. , expected sequence). For example, it may be that if the user actions result in two consecutive failed attempts in a row, the device becomes inoperable for three seconds. If user action results in three consecutive failed attempts in a row, the device becomes inoperable for thirty seconds. If user action results in four consecutive failed attempts in a row, the device becomes inoperable for three hundred seconds. In some embodiments, the time during which the device becomes inoperable can be extended exponentially (or by any factor) for every failed attempt.

[0193] Once the unlock sequence is received and confirmed to be correct by the vaporizer device 121 , it will enter an “unlocked” state. The duration of the “unlocked” state is risk score dependent and the risk score dependent logic is stored on the firmware of the device.

[0194] In some embodiments, the vaporizer device 121 may set conditions for when and how the device will relock again (i.e., how long the device will remain unlocked) based on the risk score communicated to it during the unlocking event by server 140. For example, for a raw risk score of 1 (highest risk), the vaporizer device may remain unlockedfor 1 day, for a raw risk score of 2 (high risk), the vaporizer device may remain unlocked for 2 days, for a raw risk score of 3 (medium risk), the vaporizer device may remain unlocked for 7 days, for a raw risk score of 4 (low risk), the vaporizer device may remain unlocked for 30 days, and for a raw risk score of 5 (lowest risk), the vaporizer device may remain unlocked for 30 days.

[0195] In other embodiments, the relocking condition may not be time-based, and could instead be based on any sensor, or counter, that can form part of the vaporizer device 121. For example, other relocking conditions may be based on the number of draws a user might take on the vaporizer device 121 , the number of different pods / consumables the vaporizer device 121 is used with, the number of times the vaporizer device 121 is charged, the information produced by the ODRA module 204, or any combination of these.

[0196] These relocking conditions may be stored in the firmware of the vaporizer device 121 , which may be initialized and versioned during manufacturing. As such, server 140 can predict when the next relock of a vaporizer device 121 will occur and proactively keep the user informed on relocking behavior.

[0197] In case of connected devices, the re-lock command may also be received by the vaporizer device 121 from the mobile communication device 110 and / or the server 140 via bluetooth or other radio signals, or via sound or light generated by the mobile communication device 110 or any other suitable external device able to send such a signal to the vaporizer device 121 , such as those running the anti-hub application described elsewhere herein. In some embodiments, such a signal would override the previously registered relocking durations discussed above.

[0198] While the applicant’s teachings described herein are in conjunction with various embodiments for illustrative purposes, it is not intended that the applicant’s teachings be limited to such embodiments as the embodiments described herein are intended to be examples. On the contrary, the applicant’s teachings described and illustrated herein encompass various alternatives, modifications, and equivalents, without departing from the embodiments described herein, the general scope of which is defined in the appended claims.

Claims

CLAIMS1. A dynamic risk assessment system for drug delivery devices and associated consumable products, the system comprising: a requesting device operable to generate a request triggered by a request event made by a requesting user, the request comprising request information relating to the request event and being associated with a registered user of the system; and a risk engine adapted to receive the request information from the requesting device, behavioral information relating to operational characteristics of one or more devices associated with the registered user, and intrinsic information associated with personal characteristics of the registered user, wherein: the risk engine is further adapted to infer a risk score associated with the registered user based on the request information, the behavioral information, and the intrinsic information, and the system is adapted to accept or deny the request based on the risk score.

2. The dynamic risk assessment system of claim 1 , wherein the requesting device is a drug delivery device.

3. The dynamic risk assessment system of claim 2, wherein the drug delivery device is a vaporizer device.

4. The dynamic risk assessment system of any one of claims 1 to 3, wherein the request event is a request initiated by an action of the user to unlock a drug delivery device.

5. The dynamic risk assessment system of any one of claims 1 to 4, wherein the request information comprises a unique ID associated with the requesting device and a challenge value generated by the requesting device.

6. The dynamic risk assessment system of any one of claims 1 to 5, wherein the request information further includes a risk score generated by the requesting device, the risk score being based on one or more usage characteristics of the requesting device.

7. The dynamic risk assessment system of claim 1 , wherein the requesting device is a point of sale (POS) device.

8. The dynamic risk assessment system of claim 7, wherein the request event is a request to purchase a consumable product associated with the drug delivery device.

9. The dynamic risk assessment system of any one of claims 1 to 8, wherein the request information includes point of sale (POS) information.

10. The dynamic risk assessment system of claim 9, wherein the point of sale (POS) information includes one of more of time and date information, location information, and stock keeping unit (SKU) information.11 . The dynamic risk assessment system of any one of claims 1 to 10, wherein the risk engine comprises one or more machine learning models.

12. The dynamic risk assessment system of any one of claims 1 to 11 , wherein the behavioral information includes information relating to actions taken by the requesting user and / or the registered user.

13. The dynamic risk assessment system of any one of claims 1 to 12, wherein the information relating to actions taken by the requesting user and / or the registered user include usage patterns of a drug delivery device and / or transaction patterns relating to an associated consumable product.

14. A risk-adjusted dynamic authentication method for a drug delivery device, the method comprising: receiving request information relating to a request event made by a requesting user, the request information relating to the request event and being associated with a registered user of the system; receiving a risk score associated with the registered user; selecting an authentication process from a plurality of authentication processes based on the risk score, each of the plurality of authentication processes having a different level of security and a corresponding level of difficulty to carry out by the requesting user; and authenticating the requesting user as being the registered user using the selected authentication process.

15. The risk-adjusted dynamic authentication method of claim 14, wherein the request event is a request initiated by an action of the user to unlock a drug delivery device.

16. The risk-adjusted dynamic authentication method of claim 14 or 15, wherein the request information comprises a unique ID associated with the requesting device and a challenge value generated by the requesting device.

17. The risk-adjusted dynamic authentication method of any one of claims 14 to 16, wherein the request information further includes a device risk object generated by the drug delivery device, the device risk object being based on one or more usage characteristics of the drug delivery device.

18. The risk-adjusted dynamic authentication method of claim 14, wherein the request event is a request to purchase a consumable product associated with a drug delivery device.

19. The risk-adjusted dynamic authentication method of claim 18, wherein the request information includes point of sale (POS) information.

20. The risk-adjusted dynamic authentication method of claim 19, wherein the point of sale (POS) information includes one of more of time and date information, location information, and stock keeping unit (SKU) information.

21. The risk-adjusted dynamic authentication method of any one of claims 14 to 20, wherein the plurality of authentication processes includes one or more of a one-time- passcode (OTP) authentication, a personal identification number (PIN) authentication, biometric authentication and likeness authentication.

22. The risk-adjusted dynamic authentication method of any one of claims 14 to 21 , wherein the drug delivery device is a vaporizer device.

23. A non-transitory computer program product comprising computer-implemented instructions to cause one or more computer systems to execute the method of any one of claims 14 to 22.

24. An access control method for a drug delivery device, the method comprising: receiving a unique device identifier associated with the drug delivery device and a dynamic challenge value generated by the drug delivery device; retrieving a secret encryption key associated with unique device identifier; generating an unlock sequence based on the secret encryption key and the dynamic challenge value; and sending the unlock sequence to the drug delivery device, the drug delivery device being operable to be unlocked when the unlock sequence is input into the drug delivery device.

25. The access control method of claim 24, wherein the method further comprises: retrieving a unique user identifier associated with the unique device identifier; and retrieving a risk score associated with the unique user identifier, the risk score being indicative of the likelihood that the drug delivery device is being user outside a set of use policies, wherein the step of generating an unlock sequence further comprises generating the unlock sequence based on the risk score.

26. The access control method of claim 25, wherein the one of the policies in the set of use policies is that the drug delivery device must be used by the user associated with the unique user identifier.

27. The access control method of any one of claims 24 to 26, wherein the drug delivery device is a vaporizer device.

28. The access control method of any one of claims 24 to 27, wherein the step of receiving a unique device identifier associated with the drug delivery device and a dynamic challenge value generated by the drug delivery device includes receiving the unique device identifier associated with the drug delivery device and the dynamic challenge value generated by the drug delivery device via Near Field Communication (NFC) technology implemented on the drug delivery device and a mobile communication device.

29. The access control method of any of claim 27, wherein the unique device identifier associated with the drug delivery device and the dynamic challenge value generated by the drug delivery device are encoded in a Uniform Resource Locator (URL), which is configured to cause the mobile communication device to open a web application in a browser of the mobile communication device.

30. The access control method of claim 27, wherein the unique device identifier associated with the drug delivery is encoded in a Uniform Resource Locator (URL), which is configured to cause the mobile communication device to open a web application in a browser of the mobile communication device, and wherein: the drug delivery device is configured to display the dynamic challenge value to a user of the mobile communication device, and the web application is configured to allow the user to input the dynamic challenge value into the web application.

31. The access control method of claim 27, wherein the unique device identifier associated with the drug delivery is encoded in a Uniform Resource Locator (URL), whichis configured to cause the mobile communication device to open a web application in a browser of the mobile communication device, and wherein: the drug delivery device is configured to display the dynamic challenge value to the mobile communication device, and the web application is configured to use the mobile communication device to capture the dynamic challenge value from the drug delivery device.

32. The access control method of claim 31 , wherein the web application is configured to use the camera of the mobile communication device to capture the dynamic challenge value from the drug delivery device.

33. The access control method of any of claims 30 to 32, wherein the drug delivery device is configured to display the dynamic challenge value using a plurality of light emitting diodes (LEDs).

34. The access control method of any one of claims 30 to 32, wherein the drug delivery device is configured to display the dynamic challenge value using a visual display.

35. The access control method of any one of claims 24 to 34, wherein the drug delivery device is configured to generate the dynamic challenge value using a random number generator (RNG).

36. The access control method of any one of claims 24 to 35, further comprising inputting the unlock sequence into the drug delivery device.

37. The access control method of claim 36, wherein the step of inputting the unlock sequence is performed by the mobile communication device.

38. The access control method of claim 37, wherein the step of inputting the unlock sequence is performed by the mobile communication device using wireless data communication.

39. The access control method of claim 36, wherein the web application is operable to display the unlock sequence to the user via the mobile communication device and the step of inputting the unlock sequence is performed by the user using inputs means of the drug delivery device.

40. The access control method of claim 39, wherein the input means of the drug delivery device is a push button switch.41 . The access control method of any one of claims 25 to 40, wherein the risk score is used by the drug delivery device to restrict access to the drug delivery device by a user.

42. A system for controlling access to drug delivery device, the system configured to carry out the method of any one of claims 24 to 41 .

43. A non-transitory computer program product comprising computer-implemented instructions to cause one or more computer systems to execute the method of any one of claims 24 to 41.

Images