Patent Application
20210187144
The invention relates to a fragrance system that is fan assisted; the system can provide a fragrance within a room, home, car, office or other environment.
Fragrance systems for home and other environments typically rely on air currents in that environment to carry fragranced air; for example, porous reeds or sticks placed into a bottle of essential oils and scented candles are popular ways of fragrancing a room. But they produce only a very localized fragrance that is hard to control. Essential oil diffusers are also popular; these include a water tank which the user fills with water and adds a few drops of essential oil to the water; a small ultrasonic atomizer generates a fine mist of fragranced air. These devices can be turned on and off, but regularly replenishing these diffusers with water and essential oils can be somewhat messy and inconvenient.
The invention is a fragrance system for a room, building or other environment, the system including (a) a stand or other form of base and (b) one or more portable fragrance objects, each portable fragrance object providing a fragrance and configured to rest on the stand or base; the stand or base including one or more fans or other air movement system arranged to release fragrance from one or more of the fragrance objects.
Appendix 1 provides a more comprehensive overview of the key features.
Implementations of the invention will be described, referring to the following Figures:
One implementation of the invention is a fragrance system including (a) a stand or other form of base and (b) one or more portable fragrance objects, each portable fragrance object providing a desired fragrance and configured to rest on the stand or base; the stand or base including one or more fans or other air movement system arranged to release fragrance from one or more of the fragrance objects.
The ZenAura fragrance system has an aesthetic design and does not need to be hidden away; it can be placed in prominent areas in a room and that in turn means that effective fragrancing is possible; less attractive devices tend to get hidden away, which in turn reduces their effectiveness. It is a connected device, and yet is robust and low cost to manufacture. It does not use any liquids; it cannot cause spills, unlike conventional diffusers that use sticks placed into a fragranced oil. Because it uses powered fans, it is not reliant on air currents within a room to distribute the fragrance; it is hence far more effective in comprehensively fragrancing a room compared to conventional fragrance diffusers, which tend to produce a strong localised scent, but are unable to distribute that scent more widely in a room. Also, because the speed of the fans can be increased, it is possible to rapidly fragrance a room, something a conventional diffuser cannot do. And likewise, turning the fans off causes the fragrancing to rapidly cease. The fans can be controlled from the stand or an application running on a device, such as a smartphone or smartwatch etc. A user can hence readily and easily start and stop the controlled release of fragrance into a room, which is not possible with a conventional fragrance diffuser.
The fragrance system can automatically track how long and at what speed a fan has been active for its associated fragrance object; that enables the system to work out when the fragranced EVA matrix is likely to need replacing; an alert can be sent to the companion application, enabling the user to purchase a replacement via the companion application, for postal etc. delivery.
The surface of the EVA matrix is shaped to maximise the surface area that is presented to the air blown in by the associated fan and to then direct that fragranced air out of Pearl and into the room.
The system is a connected system, with a companion application displaying the specific fragrances of each Pearl on the stand. The application can also control the fan speed and hence the strength of the fragrance delivered by each Pearl.
In addition, the user can also create, edit and select a schedule, i.e. times during which a pre-set fragrancing will occur. In
The core features A-J can be generalised as follows:
A. A fragrance system for a room, building or other environment, the system including (a) a stand or other form of base and (b) one or more portable fragrance objects, each portable fragrance object providing a fragrance and configured to rest on the stand or base; the stand or base including one or more fans or other air movement system arranged to release fragrance from one or more of the fragrance objects.
B. A portable fragrance object including a fragrance infused substrate or matrix, the object being configured to rest upon a stand or base or be placed upon that stand or base by a user; and configured to permit air, blown from one or more fans or other air movement system positioned in the stand or base, to pass over the fragrance infused substrate and out into a room, building or other environment.
C. A portable fragrance object that is shaped like a smooth, rounded pebble or a flat-based ovoid, and is configured to rest upon a stand or base or be placed upon that stand or base by a user; and has (a) a wall that encompasses or covers a fragrance infused substrate or matrix and (b) one or more air passageways between the outer surface of the substrate or matrix and the inner surface of the wall.
D. A portable fragrance object with (a) a wall that encompasses or covers a fragrance infused substrate or matrix, in which the substrate of matrix has a surface that is shaped or contoured to direct incoming air from a fan over channels, grooves, arches or other features in the substrate or matrix to increase the surface area of the substrate or matrix that is exposed to the incoming air.
E. A portable fragrance object including a fragrance infused substrate or matrix, and an ID chip or device (such as a wireless chip, e.g. an RFID chip) that exchanges data with a base, stand, or other type of dock that includes one or more fans, to authenticate the fragrance object and to hence permit operation of a fan with that fragrance object.
F. A portable fragrance object including a fragrance infused substrate or matrix, and an ID chip or device (such as a wireless chip, e.g. an RFID chip) that exchanges data with a base, stand, or other type of dock that includes one or more fans, to trigger a light or illumination in the dock when the portable fragrance object is sufficiently close.
G. A portable fragrance object including a fragrance infused substrate or matrix, and an ID chip or device (such as a wireless chip, e.g. an RFID chip) that exchanges data with a base, stand, or other type of dock that includes one or more fans, to trigger a nozzle or aperture to rise up from the dock, the object being configured to engage with the nozzle or aperture.
H. A portable fragrance object with (a) a wall that encompasses or covers a fragrance infused substrate or matrix and (b) one or more air passageways between the outer surface of the substrate or matrix and the inner surface of the wall, the air passageways being arranged to take incoming air blown from a fan directed at the substrate or matrix and to pass it over the substrate or matrix to add a fragrance to that air and to then duct the air out from the fragrance object.
I. A method of adding fragrance to a room, building or other environment comprising the steps of placing a portable fragrance object as defined above on a stand or base including one or more fans or other air movement system arranged to release fragrance from one or more of the fragrance objects and then activating the fan or air movement system.
J. A method of adding fragrance to a room building or other environment comprising the steps of:
(a) placing a portable fragrance object as defined above on a stand or base including one or more fans or other air movement system arranged to release fragrance from one or more of the fragrance objects and then activating the fan or air movement system;
(b) automatically determining that the fragrance object is coming to the end of its useful life by tracking the extent of its use;
(c) automatically sending a request to an app and/or remote fulfillment server for a replacement fragrance object to be supplied.
Optional features. Each can be combined with any one or more other optional features and with any of the core features A-J described above.
1 Main System Components
The ZenAura system is based on a platform or stand, called the diffuser, which supports placements of containers of fragrances, called Pearls.
A Pearl is made up of
The diffuser will be a cosmetically pleasing carrier and will perform the following basic functions.
There will be three types of diffuser available.
A system level diagram of the electronics of the diffuser is shown at
There will be a controller PCB attached to the central Pearl station. It will contain all of the electronics for the system apart from the switch PCBA, and the motors, fans and LEDs in the individual Pearl stations, as shown in
The WiFi will be implemented may be implemented as a chip laid out directly onto the PCB. The antenna will also be laid out on the PCB according to the recommendations given by TI. The WiFi circuit should be positioned so that the RF is not interfered with by the rest of the circuit and the antenna has a clear “view” of the front of the diffuser. Consideration needs to be given to the material used in the case and bezel to ensure that it does not unduly attenuate the WiFi signal
The connectors for the motor, and fan signals shall be placed so that the cables for all three stations can be short and all the same length.
The MCU will generate the phase signals for the stepper motor. These will be translated to bi-polar signals by a specific h-bridge driver. It is only necessary to drive one motor at a time, which means that the output of a single driver chip may be used to control all motors in the system. The signals can be individually controlled by means of analogue switches or FETs. Consideration should be given to back EMF and any damage that this might cause. This will also have the advantage of using less GPIO from the processor. The position of each motor will be determined by an IR switch which will be interrupted by the movement of the CAM. To save circuitry the output from all three IR switches will be multiplexed together again with FETs or an analogue switch to an AtoD input on the processor, as shown in
The buffer for the LEDs can be a simple transistor. The intention is to use one PWM signal to control the variable brightness of the LEDs on driver all three pearl stations. However, there will need to be a switch to turn each off individually.
Each fan will need to have its speed controlled separately. Again simple transistor buffers should be adequate to drive the fans themselves. Note that fans have considerable inertia and back emf which means that it is difficult to accurately control their speed by PWM'ing their supply. Four wires fans with separate PWM signals may be required, although these are likely to be more expensive.
The power input will come from an external mains to dc supply via the Power PCB. The power will have to be regulated down for the digital circuitry and will also be supplied to the fan and motor. Careful consideration will be given to the layout and decoupling so that the electrical noise generated by the motor and fans does not adversely affect the more sensitive electronics parts such as the RFiD readers and RF, and the WiFi controller and RF. A possible power architecture is shown in
Provision should be allowed for an 18650, or similar, lithium ion battery to be placed in the diffuser. The battery will require a PMIC that will need to charge it as well as up convert its output to the various power supplies required, including the fans and motors. The battery voltage should be supplied to an A to D input into the processor to give an approximate indication of the battery charge state. The system will also require a button cell to maintain an RTC. Current should only be drawn from the button cell when the diffuser is not plugged into a power supply, or the rechargeable battery is flat.
The RFID antenna for the each of the pearls will be laid out on the main PCB, which will be extended to cover the three pearl stations, as shown in
It is hoped that a single RFiD reader chip will be able to read all three pearl stations by multiplexing the RF connection to each antenna. There are specific RF multiplexers that might be used, but also analogue switches should have the required bandwidth to be used. These are much cheaper and more readily available than specific RF chips. The layout of the tracks on the PCB will be crucial to achieve a good design. The RF signals should be laid out as a controlled impedance tracks and simulate a coax cable. Any noisy digital signals should be kept well away from the RF routing. The RFiD antennas should be well clear of any ground plane. The mux should be one that is matched to the circuit, has minimum injection loss and return loss at the RFiD frequencies.
The apple co-processor will be laid out on the PCB, but the current plan is that it will not be fitted.
The main controller PCB should be laid out so that it fixes horizontally in the diffuser. This will allow it to incorporate the RFiD antennas. An example of the PCB shape and placement is in
It is anticipated that the layout will require 4 layers.
There will be a small PCBA containing:
The power PCB will be mounted onto the diffuser case close to the power input. The output from the power switch will feed into a GPIO on the MCU.
The power switch will:
Note that during transportation the processor will be in the MCU Shutdown mode and the NWP will be Network disabled mode (nRESET low). A button press in this state will put the diffuser into provisioning mode.
A schematic of the Pearl fan station is shown in
The stepper motor needs to raise and lower the Pearls on command. It will be geared to provide enough to torque to overcome the inertia of the CAM.
Consideration should be given to air flow. Will it be better to have the fan push or pull air through the Pearl and Pearl station? Is there enough of a gap to the base of the diffuser to allow air to be drawn quietly and efficiently.
The RFiD antenna will be tracks on the man controller PCB. The tracking to the antenna should be impedance controlled and act like a coax cable.
The controller will need to know the position of the motor in order to re-sync it periodically. This will be done by the use of an I|R|tx/rx pair which is interrupted by the CAM movement driven by the motor. This will feed an A to D input on the MCU.
This Appendix 3 will act as both a description of the top-level requirements of the ZenAura IoT System and a definition of the various phases of the project that are part of the actual RFQ.
Called a Pearl, which is a container for fragrance with an attached RFiD tag. A Pearl is a consumable product that will need to be replaced after a certain amount of usage, e.g. a month for a typical user.
There are many different types of Pearls. During manufacture of the Pearls the type of pearl will be matched against the tag UID and uploaded into the IoT cloud database.
Called a Diffuser, on which 1, 3 or 5 pearls can be placed. The device has
The device is responsible for detecting the presence of a Pearl and sending the UID to the IOT cloud control.
The App connects the user to the IoT cloud and to the device. It has the following functions
The current platform has the concept of objects, eg
Note that there are/will be different types of diffusers and pearls. The diffuser and pearl objects are set up as they are manufactured by importing some kind of databases, maybe just a CSV files, into the system from the manufacturers. When they are imported they get assigned unique IoT IDs.
The database for the diffuser will contain
The database of the pearls will contain
The user is set up when they log into the App or website for the first time.
When these objects get used they get put into collections that are logically linked together, by their unique IoT ID. The process will be something like:
Note the mac address and UIDs of the pearls should be checked against the manufactured databases. If ever they do not exist or there is a flag that they have already been used, then this should be highlighted to Zenaura. Note that it should be possible to have a diffuser be controlled by more than one App/user. The mechanism to do this can be decided at a later stage.
Actions should be implemented with as little delay as possible to convey the quality of the system. Eg if a user presses play on their App the resultant action on the diffuser should happen within one second. For example: play/stop action
Or diffuser software update action
All actions should be permanently logged in the system for future analysis.
To easily view the status of the diffusers, users, pearls, we will require a dashboard to be accessible for Zenaura to view. The dashboard will show the Unique IDs of the object, and its status, eg a diffuser should show
The RFQ will be to implement a similar system based on the AWS IOT platform.
Everything in AWS gets assigned an ARN. The App and diffuser will talk to endpoints that are determined by the ARN of the item it is communicating to. For example a diffuser ARN may look something like “arn:aws:iot:us-east-1:123456789012:thing/diffuser3A_123456789abc”
There will be at least two databases maintained in the cloud, one for diffusers and one for pearls. After a diffuser or a pearl batch is manufactured the relevant cloud database will be updated with the details of all products manufactured, including UIDs and any other information relevant for thing generation later on. All default attributes created during provisioning will be loaded from the database.
The AWS platform defines things with attributes and shadows. Things are physical devices, shadows are a JSON document that holds the status, or the requested status for the thing if it is offline. Attributes are searchable ways of describing the thing.
A diffuser thing will be created at the point when the user provisions/connects it to the cloud. Its attributes will be copied from the device database to the thing at this point. Each will be created with a name (ARN) that is consistent with its UID contained in the database. It's attributes will be copied over from the database.
The diffuser shadow will be created at the same time as the thing.
A pearl thing will be created at the point when it is first used on a diffuser. Each will be created with a name (ARN) that are consistent with their RFiD UID which has been programmed in during manufacture. Initially the pearl will be assigned to an unused group.
A user thing will be generated when a user initially signs in with their first App. They will therefore be generated one by one as the user logs in. Each user will have a UID that is reflected in their ARN.
An App thing will be generated when a user initially signs in with an App. They will therefore be generated one by one as the user logs in. Each App will have a UID that is reflected in its ARN.
Each User will form a group within which will be placed their Apps, diffusers and pearls. Normally only one user will be allowed in any one group, and only that user can control the things within that group. For example, a pearl assigned to one user, can only be used by diffusers within the same group. A user can give permission for another user to share the group and all things within it.
The pearl is a commodity product and has an associated lifetime. The lifetime will be calculated by the cloud according to an algorithm that is yet to be decided, but will have as inputs
Once the lifetime has expired the pearl thing will be marked as dead (or just simply deleted), the database updated to reflect this, and the cloud will log but reject any command to use it.
The AWS platform has user authentication process built in called Cognito. The App will use this to authenticate the user.
Scenario—A user has bought a diffuser, turned it on, and logged into their downloaded. They tap the add new diffuser button on their phone.
Things are assigned to user groups and it is not normally possible for another user to send commands to them. However, there are exceptions.
6.8.1 A Diffuser being Shared by Other Users
It should be possible for another user to connect to an existing assigned diffuser, but permission from the original user will be required first. This permission will mean that the second user has access to the entire group of the first user.
In this case the provisioning process for the second user is unnecessary.
6.8.2 A Diffuser being Deleted by a User
A user can give up control of their diffuser by deleting it from their group. In this case the diffuser will go to an unassigned group. The diffuser must be re-provisioned before it can be used in another group.
The diffuser will use MQTT exclusively to communicate with the IoT cloud. The app will use RESTful commands or potentially AWS SNS. The App will communicate with the thing shadow, which will then update the Thing and the physical diffuser.
The AWS IoT platform provides a service to perform remote actions on multiple devices. These are references as Jobs. An OTA mechanism will be a job that will be required by Zenaura.
6.11 Zenaura Device Management
Zenaura will need to be able to monitor usage of diffusers and pearls and to analyse the usage with a number of algorithms. The exact method of doing this has yet to be determined, but a thing registry will be helpful.
The AWS Device Management Service provides an API.
The CRM system will have access to the IoT database for:
A top level diagram of the system is shown at
The API between the IoT system and the CRM system will look like the following:
We have an area in AWS to hold downloadable content for the App including editorial, shop.
Example messages to/from the App
Commands will use three phases:
Changes to the pearl RUM status will use two phases:
If the diffuser doesn't receive the PUBACK then it re-transmits the status message every minute until it does.
An example messages sent to the diffuser via the _Play endpoint is:
[{“pearlindex”:0, “fanspeed”:100, “lightintensity”:50,“duration”:10}]
The diffuser will respond by publishing its status back to/things/xxxx/attributes. This can be an array of messages with different ‘timestamp’ times. For example:
[{“timestamp”:12345678, “key”:“fan0speed”, “value”:100},
{“timestamp”:12345678, “key”:“light0intensity”, “value”:90},
{“timestamp”:1234-5678, “key”:“fan1speed”, “value”:80},
{“timestamp”:12345678, “key”:“light1intensity”,“value”:70}
The diffuser will publish pearl ID status messages to /objects/xxxx/actions/_PearlAdded. This May be at the same time as the properties are updated or only when a pearl is added. For example:
{“type”:“_PearlAdded”, “projectid”:“xxyyzz”, “timestamp”:12345678, “customFields”:{“pearlindex”:2, “pearlid”:“ABCDEFG”}}
When the pearl is removed, the diffuser will publish a message to /objects/xxxx/actions/_PearlRemoved. For example:
{“type”:“_PearlRemoved”, “projectid”:“xxyyzz”, “timestamp”:12345678, “customFields”:{“pearlindex”:2}}
The IoT platform responds to status and pearl ID updates with a PUBACK message to confirm receipt.
Q
Schedules can be set by publishing an array of (cron timestamp,command) pairs to _Schedule. The command is the same format as above. For example:
[{“time”:“* * * * *”, “command”:[{“pearlindex”:0, “fanspeed”:50, “ledintensity”:100,“duration”:30}]},
| Number | Date | Country | Kind |
|---|---|---|---|
| 1718324.5 | Nov 2017 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/GB2018/053215 | 11/6/2018 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62598510 | Dec 2017 | US |
