The present disclosure provides several embodiments of a module-driven smartwatch. A leading aspect of a module-driven smartwatch is that it automatically reconfigures its user interface and experience based on the modules that are attached to it. In one embodiment, the module-driven smartwatch comprises a frontend processing unit powered by a primary battery and mainly configured for time-keeping and user-interfacing, a backend processing unit mainly configured for providing conventional “smartwatch”-like capabilities, and a module connector. In this embodiment, the backend processing unit's operation is contingent on power provided by a module connected to the module connector. In another embodiment, the module-driven smartwatch is much the same as a conventional smartwatch, except for its user interface and experience being driven by module attachment, operation and removal. In all cases, a module-driven smartwatch enables hardware extensibility and/or substitution without requiring smartwatch replacement.

FIELD OF APPLICATION

The present disclosure relates generally to electronic devices and, more particularly, to what is commonly-known as “smartwatches.”

BACKGROUND

For centuries, portable time-pieces were fabricated using mechanical gears and springs; first primarily as pocket watches and later, in the late 1800s and early 1900s, as wrist-worn watches. The 1970s saw the rise of electronic, quartz-based watches which, by the 1980s, had largely supplanted mechanical watches as the primary means for personal time-keeping. The 1970s and '80s also saw the rise of personal computing with the introduction of several key systems targeted at home buyers and individuals such as the Apple II™ and the IBM™ PC. Thus, since the 1970s, there have been several attempts at creating electronic watches that would combine some form of computerized capabilities along with time-keeping in the form of a wrist-worn device. At the time of this writing, such devices are commonly-referred to as “smartwatches”. For the purposes of the present disclosure, a “smartwatch” is therefore a wrist-worn device providing some form of computerized capabilities along with time.

While the early smartwatches' capabilities were geared towards rudimentary data storage or calculator-like functionality, the 1990s and the early 2000s saw an increasingly wide array of computing-like capabilities being incorporated into smartwatches, including for example calendar and contact synchronization with users' computers. Still, for the most part such offerings and capabilities remained confined to niche markets. The last few years, however, have seen accelerated efforts by a large number of industry players, including very large consumer electronics vendors, to integrate into smartwatches many of the same features and/or technologies that have become mainstream as part of their inclusion in smartphones. At the time of this writing, for instance, there are therefore a large number of smartwatches on the market that combine features such as touch display, high-end processing capabilities, gyroscope, accelerometer, voice recognition, network connectivity through Bluetooth™, Wifi™ and/or cellular connection, etc.

The current crop of smartwatches, as they are promoted by most players in the industry, seem to be centered around the concept of providing highly-capable/integrated general-purpose smartwatches that enable software developers to tailor a smartwatch's use to provide a specific functionality to their user by way of developing a custom application that is loaded and run on the smartwatch. That is, most vendors are attempting to replicate the model popularized by smartphones where the user owns a highly-integrated device and uses different apps to accomplish different tasks on the same device. Such is the case for the smartwatches currently promoted by Apple™, as the Apple Watch™, and the different manufacturers that release smartwatches running Google's™ Android Wear™ operating system (OS).

In all those cases, the consumer is offered a self-contained, highly integrated smartwatch that combines all the electronics and the capabilities that the user could potentially need to run the software applications that are to be loaded onto their device using the application ecosystem their device belongs to, be it Apple's or Google's. Much like the smartphone ecosystems, the differentiation between such smartwatches is therefore based on the full list of technical specifications available at the time the watch is manufactured. This therefore typically means that the watch contains more hardware than the user effectively needs at any point in time since most apps tend to require only a subset of the overall capabilities of the smartwatch, and the user generally uses only a single or a very limited number of apps at most at the same time. Conversely, should new hardware features be required or introduced, or older features be upgraded, the consumer is expected to purchase a new smartwatch. Given that such smartwatches can be relatively expensive, it can be difficult for users to justify a replacement cycle similar to that found in the smartphone market, especially since, unlike smartphones, the purchase of a smartwatch is unlikely to be bundled in their carrier's customer plan.

More importantly, outside the realm of use-case-specific smartwatches, such as for example fitness/exercise-tracking and health-monitoring, like the Fitbit™ and Garmin™ line of fitness trackers, the appeal of general-purpose smartwatches incorporating many smartphone-like capabilities in a smaller form-factor remains limited. Several reasons have been circulating within the industry to explain this, namely:

Limited battery life
Tiny screen size
Constrained entry capabilities
Dependence on smartphone: requires a smartphone to function and/or requires a specific make/model to function
Dependence on the cloud
Size and weight
Reliability of measurements
Each of these is further discussed in detail below.

One of the primary issues with smartwatches is their limited battery life. Indeed, some watches, such as the Apple Watch and many Android Wear-based watches need to be charged on a daily basis. Some smartwatches fare a bit better and only require a charge every week, with some even lasting for as long as 10 days. Such is the case for some Garmin models, the now defunct Pebble and the Qualcomm Toq concept smartwatch. Still, even at those rates, no smartwatch fitting the current definition gets anywhere near the longevity provided by classic quartz-based watches which can last for more than a year, sometimes several years, on a single coin-cell battery. Even early 1980s smartwatches, such as the Seiko UC-2000 and Data-2000 could last at least several months without requiring a battery change. Such watches did not obviously have the same feature-set as present-day smartwatches, but they did however provide the user with the primary functionality they were wearing the device for: having the time available on their wrist at all times.

There are several reasons why modern-day smartwatches' batteries require constant charging. One of the main reasons is that, as alluded to earlier, manufacturers design smartwatches to be highly integrated devices such as smartphones. Hence, smartwatches end up containing several dozen specialized hardware components to cater for every conceivable use-case the manufacturer believes the smartwatch is meant to address. Every such component and/or integrated circuit requires battery power. Each component individually may not draw a lot of power, but combined together the components overall draw more than can be accommodated for a very long duration by a battery of the size that can fit in a smartwatch. That's especially true if the user starts using apps on their watch that bring some components out of their quiescent state and into full power mode where they consume even more power than when they are unused.

Another reason why smartwatch batteries tend to not last very long is that most manufacturers operate on the assumption that users want to have the same kind of high-definition color display that is found on smartphones. Such displays, especially ones that are readable in high ambient light conditions, such as sunlight, are very power hungry. As such, most manufacturers attempt to put in place several optimizations that keep those displays' power consumption at a bare minimum for most of the time. Some keep the displays off until a certain wrist movement is operated by the user, thereby triggering the display to come on and provide the time. Other manufacturers put the display in a low power consumption mode where the time is faintly visible, thereby making it possible for the user to consult the time at all times, but then turning the display fully on when the user is actually interacting with the device. Yet another optimization implemented on smartwatch platforms is to use darker display backgrounds for most screens since white backgrounds are more power hungry. While such tricks are interesting optimizations, they remain insufficient to meaningfully extend smartwatches' operation.

It remains that the physical space inside a smartwatch is limited and, as was mentioned earlier, this limits the size and therefore the capacity of a battery. Traditional coin-cell batteries that can fit in a regular quartz watch can traditionally store up to around 200 mAh. Rechargeable LiPo batteries such as those found in smartwatches can be around 200 to 300 mAh, or sometimes a bit more. In contrast, it's not uncommon to find smartphones with an order of magnitude more of battery capacity. Hence the typical approach taken at the time of this writing by smartwatch manufacturers of trying to fit many of the features found in smartphones into the much smaller smartwatch form-factor practically guarantees that the lack of battery capacity will be an irritant to users.

Another issue with smartwatches is the limited size of their screens. Indeed, by trying to mimic an app experience similar to that of smartphones but on users' wrists, manufacturers and designers end up having to find convoluted ways to display vasts amounts of information and/or app navigation interactions on a very tiny screen real-estate. The fact is that current smartwatches being general-purpose devices, the user must first typically navigate through the tiny screen to the app they wish to interact with before they can then proceed to launching the app and benefiting from its functionality.

Not only does the limited screen size make the navigation to the app difficult, but it also limits the possible interactions with the app itself. Indeed, apart from the predefined gestures and capabilities provided by the platform on which the app runs on and the existing buttons found on the smartwatch, an app cannot provide any other way of interacting with it to the user. Instead, since many smartwatch apps act as companion modules to smartphone apps, the smartphone app is designed to contain the full set of functionality whereas the companion smartwatch app contains only a limited subset of the overall functionality, the complete set being only available to the user when operating the app from their smartphone.

A further limitation of smartwatches is their dependence on users' phones in order to operate properly and/or provide their full feature set. Indeed, up to very recently, the Apple Watch and Android Wear required direct tethering to a smartphone in order to operate. More recent versions of those systems have included the ability to operate without being directly tethered to a smartphone, but much of their functionality remains predicated on the user's smartphone as described earlier. Some smartwatch models, such as the Apple Watch, cannot be operated using anything but a matching smartphone make and/or model, an iOS phone in the case of the Apple Watch. This too is an inconvenience to users who are forced to choose a fixed combination of hardware products instead of being able to selectively choose which product best matches their needs.

Another common dependence for smartwatches is the requirement to use the app ecosystem and/or cloud services matching the operating system (OS) running on the smartwatch. Indeed, both Apple's watchOS™ and Android Wear depend on the respective cloud services to operate. It's either inconvenient or impossible for a user to operate their smartwatch independently of those cloud services. This too is a limitation to users' freedom as they cannot fully freely operate their smartwatch using the services of their choice.

Another issue with some modern-day smartwatches is their size and weight. Indeed, given the high level of integration found in smartwatches, there are a great deal many components packaged into a single constrained housing. Furthermore, given the battery issues mentioned earlier, smartwatch rechargeable batteries must contain enough capacity to provide an acceptable experience to the user. Effectively, this means that the batteries for smartwatches containing powerful hardware must be physically large, therefore contributing to the size and weight of smartwatches. While such issues are subjective, it remains that the level of integration and battery requirements dictated by current designs create a situation where it's difficult to minimize the size without sacrificing functionality.

Yet another issue with some smartwatches and fitness trackers is that the measurements they provide regarding activity tracking can be somewhat unreliable. Indeed, some cursory investigations by trade press have found that some of the information reported by smartwatches can be misleading. Since smartwatches are integrated devices with non-interchangeable parts, it's therefore impossible to remedy this situation once the device has shipped, unless the issue was in software only. If the issue is due to hardware, the only solution for users is to replace the smartwatch.

While several of the above issues with smartwatches remain unanswered by the current market offerings, it isn't the present disclosure's purpose to necessarily address them all or the entirety of those it attempts to address. The aforementioned issues are presented here to provide the background and contemporaneous context of the present disclosure.

There is thus a need for a smartwatch that does not necessarily attempt to include all hardware required for every potential use case within a highly-integrated, general-purpose design.

There is therefore a need for a smartwatch whose hardware can be extended and/or modified after it is manufactured.

There is therefore also a need for a smartwatch whose design prioritizes battery life over integrated functionality.

There is thus also a need for a smartwatch that ensures that time can be displayed to the user for an extended period of time without necessitating battery replacement or recharging.

There is therefore further a need for a smartwatch that enables the minimizing of on-screen navigation and interaction to obtain a certain functionality.

There is therefore also a need for a smartwatch that provides interaction mechanisms and/or design elements that are tailored for the form-factor limitations of and variations afforded by a wrist-worn device.

There is additionally a need for a smartwatch whose weight can be optimized by reducing the quantity of components integrated within the confines of its limited housing.

There is therefore further a need for a smartwatch built around a hardware architecture that enables a certain degree of functionality replacement and extensibility.

SUMMARY OF THE INVENTION

An object of the present disclosure is to provide a module-driven smartwatch that overcomes at least one of the previously-listed drawbacks and that satisfies at least one of the above-mentioned needs.

Another object of the present disclosure is to provide a module-driven smartwatch that relies primarily on interchangeable modules in order to provide task-specific functionality.

According to the present disclosure, there is provided a module-driven smartwatch that:

provides basic watch-like (time-keeping) capabilities such as time, date, and alarm;

is capable of providing computerized capabilities; and

is connectable to at least one module;

wherein the computerized capabilities are active primarily, though not exclusively, when an at least one module is connected to the module-driven smartwatch.

According to the present disclosure, there is further provided a method for providing function-specific capabilities to a smartwatch by way of using modules.

It is hereby noted that for brevity purposes, both the figures used in the present disclosure and the following text use the acronym “MDS” instead of “module-driven smartwatch”. All instances of “MDS” should therefore be read in context as “module-driven smartwatch”. For example, “MDS module” stands for “module-driven smartwatch module”. Furthermore, note that the use of expressions such as “current-day”, “contemporary”, “conventional”, “traditional”, “regular” or any similar term in relation to the term “smartwatch” refers to the state of the art, the market offerings and the technologies most widely prevalent with regards to smartwatches at the time of the writing of the present disclosure.

In one embodiment, an MDS is preferably, but not necessarily, a wrist-worn device whose primary function is to provide time while being capable of advanced, current-day smartwatch-like capabilities when a module is attached to it. Therefore a distinction between a conventional smartwatch and one of the embodiments of the MDS could be that the former's computerized capabilities are effectively available at all times whereas the latter's computerized capabilities would be meant to only be available when a module is connected. This wouldn't preclude those computerized capabilities from being enabled at other times for limited amounts of time and/or with proper power being supplied to the module and/or MDS, but it would contrast with current-day smartwatches where computerized capabilities are meant to be available almost at all times, typically when the user interacts with the smartwatch or when some form of notification occurs. In other words, the normal operation of one of the embodiments of the MDS could be that its computerized capabilities would typically, but not necessarily, be enabled as a result of the connection of a module and disabled on the module's disconnection. Said computerized capabilities could also be enabled exceptionally under other circumstances for this embodiment of the MDS, including following user interaction. Such enabling would, however, be considered an infrequent or uncommon use-case for such an embodiment of the MDS.

In such an embodiment, at its most basic level, the MDS would contain the necessary hardware and components to function as a basic watch for a prolonged period of time without requiring frequent battery recharging nor replacement. In other words, this embodiment of the MDS could typically, but not necessarily, provide time for several weeks, months or years at a time, in contrast with current smartwatches that can only hold power for several hours or days at a time. Such basic watch-like functionality would not preclude this embodiment of the MDS from having some form of computerized capabilities in addition to the watch-like functionality when a module is not connected to it, but those computerized capabilities would be typically, but not necessarily, fairly constrained and insufficient to provide what users would generally recognize as comparable to a current-day smartwatch. In this same embodiment, the MDS would also contain the required hardware to enable advanced smartwatch-like capabilities and functionality to be provided to the user upon the attachment and/or pairing of a module.

In another embodiment, the MDS may function as a regular fully-featured, always-on/always-active smartwatch with modules providing function-specific capabilities. The details outlined earlier and below would remain similar but there wouldn't necessarily be the need to divide or qualify the MDS' functional capabilities into different degrees based on the present or absence of a module. Such a smartwatch would likely have some of the same drawbacks as conventional smartwatches, such as short overall battery life, but it would have many of the benefits and/or features of the module-driven approach described in the present disclosure.

Modules can be function-specific and enable functionalities such as providing:

incoming notifications from smartphone
fitness tracking
remotely-accessible storage
music playback through either Bluetooth or an audio jack
audio recording via a microphone
sleep tracking
health tracking (heartbeat, pulse oximeter, etc.)
cellular connectivity
camera capabilities
gluco-meter capabilities
bar-code or QR-code reading
user-customizeable or user-extendable capabilities (for makers for example)
Many other functions may also be envisioned and provided as modules. Modules may also combine several functionalities together. This, therefore, could enable the creation of general-purpose modules that externalize some or much of the capabilities typically bundled inside a traditional smartwatch. In some configurations it may even be desirable for modules to be stackable, thereby enabling multiple modules to be connected together.

Modules may additionally include connectivity capabilities including, but not limited to, Bluetooth, Wifi, GSM, CDMA, GPS, NFC, RFID, IrDA, mesh networking or any other kind of radio frequency (RF)-, audio frequency-, electromagnetic spectrum-, or, more generally, wireless-enabled connectivity. Wired connectivity capabilities could also be included in modules thereby enabling the MDS to connect to further forms of communication. Examples of such wired connections include, but are not limited to, general-purpose connections such as USB (with the MDS being either host and/or device), Ethernet, RS232, eSATA, HDMI, DisplayPort, audio jack, or Thunderbolt, special-purpose connections such as SPI, I2C, GPIO, PWM, UART, CAN bus, or even a custom wired connection type. The MDS may also include several types of connectors for attaching several types of peripherals. The MDS may, for example, have slots to attach a MicroSD card or a SIM card or any other similarly-typed device.

Modules may also simply be a battery that provides sufficient power to the MDS, possibly to enhance or enable its smartwatch-like capabilities. Function-specific modules may also include a battery to power the module itself and/or the MDS in order to provide the functionality embodied in the module. A notification module, for instance, may comprise Bluetooth connectivity and a battery. The battery would provide the power necessary for the module to pair with the user's smartphone over Bluetooth as well as the power required for the MDS to receive, display and manage notifications for the user. A module, regardless of its type, may or may not therefore necessarily include a battery.

Module and MDS power may also be provided by other means than just battery. Indeed, power may be provided by way of the module and/or MDS being connected to a PC over USB, using kinetic movement, by way of a supercapacitor or any other means for providing power. Furthermore, the MDS may contain one or several internal power-storing and/or power-capable components such as a battery, a supercapacitor or a wrist-mouvement-powered generator. Each of these may also supplement the other. A wrist-mouvement-powered generator may, for instance, be used to recharge a battery and/or a supercapacitor found within the MDS. An MDS' supercapacitor may also be charged by a module's battery.

Modules containing batteries would preferably, but not necessarily, be rechargeable independently of the MDS. Once a Bluetooth-enabled notification module has been used for an entire day, for instance, the user may disconnect said module from the MDS and place it on a charger until the following morning. The user does not necessarily need to remove their MDS from their wrist to accomplish this. Instead, the MDS continues to provide time while the disconnected module is getting charged. The user can then reconnect the recharged module at their convenience or choose to connect another already charged module. By having several identical modules, for instance, a user may even be able to have uninterrupted access to the functionality provided by said module by cycling through a series of fully-charged module units. Such would be the case, for example, with several units of a notifications module which could be cycled through to provide constant notification capabilities without ever requiring the user to take the smartwatch off their wrist to recharge it. A recharged module may also serve to recharge an internal, unremovable battery or supercapacitor found inside the MDS.

The module may be physically-attached directly to the MDS or it may be physically separate while being remotely paired via some form of wireless protocol. Many forms of physical connectivity may be envisioned such as will be described in further detail below. It remains that a given functionality is not available on the MDS until a corresponding module providing support for that functionality is connected to the MDS, regardless of the means used to establish that connection. The MDS therefore has means for enabling the connection to modules. Said means may include direct physical connectors, connectors that operate at close proximity or wireless connections such as, but not limited to, those listed earlier.

In one embodiment, the MDS preferably, but not necessarily, wouldn't operate as a smartwatch until a module is attached to it. Given current battery technology, this would therefore ensure the MDS power is preserved to provide classic watch capabilities over a long period of time. However, this would not preclude some of the aforementioned module functionality to be included within the MDS while still the latter is module-driven. This is likely to be useful if a given functionality is required for several modules. For example, if several modules require Bluetooth then including this functionality in the MDS avoids having each module to include it as well. Still, in this embodiment the Bluetooth functionality found in the MDS for modules would only be active when a module is attached and/or connected to the MDS. This would not, however, preclude the MDS from having Bluetooth functionality for other purposes unrelated to modules, such as for providing Bluetooth functionality while no module is connected.

In another embodiment, the MDS would operate as a regular or conventional smartwatch regardless of whether a module is attached or not. The attachment of a module would enable the user to benefit from the additional functionality provided by the module, or potentially extended battery life in the case of a module comprising a battery, but the smartwatch capabilities of the MDS would be available at all times.

In typical embodiments, when a module providing a specific functionality is connected to the MDS, the MDS preferably, but not necessarily, immediately and/or automatically displays the information related to that module's capabilities on the MDS' display. If the module is for tracking fitness, for instance, then attaching it results in the MDS then showing fitness tracking information from the module in addition to or instead of the current time. The user can then start interacting with the MDS for the specific functionality provided by the then-just-connected module. This may mean that the user can then use the MDS' buttons and/or other controls to interact with a module-specific interface and/or contextual menu and/or paradigm. Preferably, but not necessarily, the user does not have to navigate a user interface to get to the controls and/or interface associated with a connected module. Instead, they are preferably, but not necessarily, made readily available to the user as the module is connected.

Modules may also provide additional user-experience opportunities than those defined by or found in the MDS. A module may, for instance, have additional buttons, knobs, LEDs, or even displays separate from the MDS. This therefore enables module manufacturers to customize their modules' user experience capabilities without being limited by the features found in the MDS.

Other features of the presently disclosed computing device and method will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate, by way of example, the presently disclosed electronic device and method.

Note that many diagrams are based on material provided in the public domain at openclipart.org. Note also that Trademarks belong to their respective owners. Trademarks in this document are first-letter capitalized.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1illustrates one embodiment of a MDS101before (FIG. 1 (a)) and after (FIG. 1 (b) and (c)) it is connected to a module102. The MDS101and the module102are connected both electrically and mechanically.FIG. 1illustrates one connector set configuration. Several other electrical and mechanical connectors can be envisioned without departing from the teachings of the current disclosure. In fact, magnetic and/or capacitive and/or other types of connectors could also be used in conjunction with or in replacement of the connectors described in the present disclosure without departing from its teachings. InFIG. 1 (a), the MDS' electrical connector103is shown as aligned to mate with the module's electrical connector104. The size, shape and specific signals carried through these connectors can change significantly without departing from the teachings of the current disclosure. An example electrical connector set will be presented in detail below.FIG. 1 (a)also illustrates part of one embodiment of a mechanical connector mechanism that can be used to connect the MDS and a module. Specifically,FIG. 1 (a)illustrates the mechanical connector lips107found in one module102embodiment and usable to hold the module in place using spring-loaded latch pins found in this embodiment of the MDS101and described later.

WhileFIG. 1illustrates the connector sets as being located on the left-hand side of the MDS101, it's entirely possible for other configurations to be used. The connectors may be located on the right-hand side instead. They may also be located at the front (where the display and glass or “crystal” are typically located) or the back (which is typically the part of the watch touching the user's skin) sides of the watch101. Modules may also be made to be connectable underneath, on front or inside the MDS101instead of or in addition to any of its four sides. The specific location and/or configuration and/or the types of connectors used between modules and the MDS101can vary significantly without departing from the teachings of the present disclosure.

The rest of the MDS101resembles the parts of existing watches. Namely it preferably, but not necessarily, has buttons108,110and possibly other forms of physical user input such as thumbwheels109or possibly a conventional watch crown. The MDS101may also optionally enable touch user input using capacitive, resistive or other such types of technologies. The MDS101may also additionally feature gesture-based input as well as voice recognition technology, or any other interface for receiving user input. Buttons and other physical entry means may also be on the front of the MDS101instead of on its side. The MDS' display112is show inFIG. 1as being square and digital. The MDS101may however feature a round display and may also use conventional rotating watch hands to display time, whether the housing itself is square, round or of another shape entirely. The specific shape of the MDS101and/or its display112, and the technology used to display information on the MDS101may vary greatly without departing from the teachings of present disclosure. The display112may, in fact, be a conventional LCD such as those found in 1980s digital watches. The MDS101typically, but not necessarily, uses a conventional wrist strap or band111to attach to a user's wrist. Such a strap or band111may be attached to the MDS101using conventional watch lugs or be attached to the MDS101through a recessed space within the watch's body. The MDS101may however rely on any other means used by any other watch in the market for attaching to a user's wrist or body.

To connect a module102to the MDS101, in the case of the connector embodiment illustrated inFIG. 1, the user aligns the module's connectors104,107with the MDS' connector103and starts sliding the module102towards the MDS101. Once the connector sets have started making physical contact, the user continues to slide the module102towards the MDS101until the spring-loaded latch pins found in the MDS trigger (i.e. lock onto the module's mechanical connector lips107), thereby locking the module102in place. To release the module102from the MDS101in the case of illustrated module connector embodiment, the user presses the release buttons105,106, thereby causing the spring-loaded latch pins found in the MDS to retract, thereby releasing the module102. Springs could also be added to the MDS101to gently push the module102away from the MDS101once it is released. Other release mechanisms can be envisioned other than the buttons illustrated inFIG. 1without departing from the teachings of the current disclosure. Instead of relying on physical buttons, for instance, release requests could also be made using the MDS' user interface. Software running on the MDS101would then instruct hardware to release the module102using some form of hardware-triggered mechanism.

Preferably, but not necessarily, once the module102is connected, as shown inFIG. 1 (b), all connectors are hidden from view and the MDS' display112changes to display module-specific information. In the case ofFIG. 1 (b), the MDS displays notification information113showing the number of missed calls and new emails. The rearrangement of the display112once a module102is plugged in can vary quite substantially without departing from the teachings of the present disclosure. A module102may also provide many other functionalities than just notifications, as outlined in the previous section.FIG. 1 (c), for example, illustrates a fitness tracking module114attached to the MDS101. In this case, the MDS' display112changes to display fitness tracking information115. In addition to displaying module-specific information, the MDS101preferably, but necessarily, provides module-specific interaction functionality through its user input capabilities (including, but not limited to,108,109,110) such as menus and dialogs.

FIG. 2illustrates several example modules.FIG. 2 (a)illustrates a module140with two buttons on its left-hand side151,152. Such additional buttons could be used to provide needed module-specific interaction beyond that possible through the MDS' own input capabilities.FIG. 2 (b)illustrates a module with a slightly-protruding height141equipped with a pivoting antenna153. This may be useful for specialized radio use-cases.FIG. 2 (c)illustrates a module142with a connector on its topside154and a battery gauge155. Such a module could be used to enable the MDS to connect to a computer/PC over USB for data syncing and/or sharing in addition to using USB power to charge the module while it's connected to the MDS.FIG. 2 (d)illustrates a slightly-wider module143. Such modules may be useful in case the hardware required to implement a module requires a larger printed circuit board (PCB) and/or if the module houses a larger battery.FIG. 2 (e)illustrates a module144with an additional display161along with buttons on its front side159,160. An additional display, or other means of conveying visual information such as LEDs, could enable modules to provide a user experience tailored to the use-case addressed by the module. Front buttons could serve as another means of physical input which may be more relevant in some contexts.FIG. 2 (f)illustrates a module145that features conventional rotating watch movements156,157with one movement showing hands for hours, minutes, seconds156and the other showing a single rotating hand157, possibly for chronograph use. This module145also features a crown158on its left-hand side. Other module variations can also be envisioned without departing from the teaching of the present disclosure.

FIG. 3 (a)illustrates an MDS101with connectors on both the left103and right-hand side118. Consequently, such an MDS101would also preferably, but not necessarily, feature release buttons for the right-hand side module116,117.FIG. 3 (b)illustrates the previously-shown fitness tracking module114connected to the left connector. Additionally, it illustrates a button module119which replaces the built-in buttons from the previous figures. The right-hand side connector could be used to connect any module that would be connectable to the left-hand side connector, albeit the design may have to take into account that the module would be rotated by180degrees. The MDS101could also be worn on either the right or left hand wrists.

FIG. 4illustrates a configuration where modules would be stackable side-by-side163,162. This would allow connecting several modules together simultaneously to the MDS. To accommodate this possibility, certain modules162would need to have connectors on both sides in order to enable other modules to connect to them as well. While there wouldn't necessarily be a limit to the number of modules that could be stacked, it would be for the user to determine how many modules they are willing to wear simultaneously while still finding the usability manageable. Either way, the MDS could have the capabilities to allow the user to select which module's information and/or user interface is to be displayed at any point in time.

FIG. 5illustrates a configuration where a module164also has a strap or band in addition to the MDS. This would provide additional support for the module either for user convenience or for design reasons. If a module is too heavy relative to the MDS101, for instance, it may be useful to hold the module in place directly. A module164may also be attached in some way to the MDS' strap or band in some circumstances.

FIG. 6. illustrates several possible displays for the MDS. (a) through (c) are featured in previous figures. (d) illustrates a display showing music playback. (e) and (f) are conventional mechanical watch hand movements with (f) showing notifications in addition to time. Such a display may be rendered on-screen using an LCD or it could in fact be made using conventional watch parts such as actual moving mechanical hands or a combination of both. (g) and (h) also feature mechanical watch movement-like time along with module-specific information. (g) shows the same fitness-tracking information shown earlier. (h) shows a combination of notifications and fitness tracking information, possibly given the attachment of a module providing both functionalities.

Note that the specific information displayed for any given module can vary greatly from the examples shown. There is nothing precluding a fitness module to display more information than just the number of steps and calories presented in the previous figures, or for notification modules to present more information than just the number of missed calls and new emails. The sample displays presented in this disclosure are only meant to exemplify the MDS' capabilities. Many other displays can be envisioned without departing from the teachings for the present disclosure.

FIG. 7illustrates a side projection of one of the embodiments of the MDS and one embodiment of a module. This figure provides a more detailed view of the connectors found in the embodiment first shown inFIG. 1. Namely, the MDS slots120where the module lips107slide in are more clearly visible. Additionally, the pins of the module's electrical connector104and the metal contacts in the MDS' electrical connector103are also shown. The number of pins and metal contacts can vary in number and in configuration without departing from the teachings of the present disclosure. So too can the specific shape and location of the various connectors both in reference to the MDS and the module, and in reference to each other.FIG. 7also shows that the MDS' electrical connector103is preferably, but not necessarily, surrounded by an o-ring121, thereby ensuring that, once the module electrical connector104is inserted, the electrical connection between the MDS and the module is water-resistant. The connectors embodiments illustrated onFIG. 7are further detailed below.

FIG. 8provides a top view of one of the embodiments of the MDS with built-in module slots120which are used to insert the module mechanical connector lips107.

FIG. 9provides a detailed cross-section view of one of the embodiments of a latching mechanism at different stages.FIG. 9 (a)shows the latching mechanism before the module102and the watch101are in contact. Note that the module102is not itself shown, only its mechanical connector lips107. In addition to the MDS' connector slots120, the latch pins122and their corresponding springs123are shown. The latch springs123ensure that the latch pins122are pushed through the slots120at all times. To facilitate insertion, both the MDS latch pins122and their corresponding module lips107are preferably, but not necessarily, beveled at matching angles. Also, the radius (“r”) of the holes in the lips107matches the radius of the latch pins122, with provisions being made for proper mechanical tolerances ensuring that the latch pins122fit with sufficient ease into the holes in the module lips107but while still ensuring a solid mechanical lock once inserted. As shown inFIG. 9 (b), the beveled contact points ensure that when the lips107engage in the slots120and come into contact with the pins122, the latch pins122compress the springs123and start freeing the way for the lips107to continue advancing in the slots120. Once the lips107are inserted far enough into the slots120, the holes in the lips107align with the latch pins122and the springs123cause the latch pins122to spring back into their original position, this time through the holes in the lips107, thereby locking the module102into place against the MDS101. When any of the release buttons (not shown)105,106,116,117are pressed, another mechanism (not shown) is used to retract the corresponding latch pin122as show inFIG. 9 (d)thereby freeing the module lips107and thereby allowing the module102to be removed from the MDS101.

Several enhancements and variations may be made to this basic mechanism without departing from the teachings of the present disclosure. Electrical circuits and contacts may be put in place to enable the MDS101to identify whether or not all four latch pins122have properly engaged through their corresponding module lips107thereby ensuring that the module102is fully secured in place. A dummy module or cover may be provided to users to ensure that the MDS slots120and electrical connector103are protected at all times from debris, dust, water and/or other material that may damage the electrical connector103and/or obstruct the MDS slots120. Another set of springs may be included to push against the module lips107as they are inserted, thereby facilitating the removal of modules102when the release buttons105,106,116,117are pressed by pushing the module102out and away from the MDS101without user intervention.

FIG. 10illustrates an alternate locking mechanism based on module pegs124instead of module lips107. In this case, the pegs124are inserted into matching MDS holes125containing a corresponding latching mechanism that holds the pegs124in place once they are fully inserted into the MDS101in a fashion similar to the previously-described mechanism.

FIG. 11illustrates a detailed cross-section of an example alternate locking mechanism at different stages. To operate effectively, the present mechanism requires two spring-loaded latches170per anchoring point instead of just one as in the previous mechanism.FIG. 11 (a)illustrates a module's peg124before it's inserted into its corresponding MDS hole125. As in the previous mechanism, both the module's peg124and the spring-loaded latches171are correspondingly-beveled to facilitate insertion.FIG. 11 (b)shows the partially-inserted peg124pressing on the latches170, thereby compressing the springs171.FIG. 11 (c)illustrates the fully inserted peg124and the latches170that were pushed back to their original position and into the groove172in the peg124, thereby locking the peg124, and therefore the module102, in place.FIG. 11 (d)illustrates how the latches170are retracted once the corresponding release button105,106,116,117is pressed, thereby allowing the peg124to be removed from the MDS hole125and, therefore, unlocking the module102. As in the previous locking mechanism embodiment, variations and enhancements may be made to the present mechanism without departing from the teachings of the present disclosure.

FIG. 12provides a frontal view of one of the embodiments of the electrical connectors of both the module102(only the module's connector104is shown) and the MDS101. While the emphasis of this figure is on the electrical connectors, the MDS' slots120are shown to illustrate their relation to the MDS' electrical connector103. Note thatFIG. 12 (a)andFIG. 12 (b)show that the slots'120position can change in relation to the electrical connector103if required. Such may be the case to accommodate a mechanical latching mechanism such as one of those described earlier.

In this embodiment, the MDS connector103is made up of a recessed space126for fitting a corresponding module connector shield129, a protruding solid tongue128in front of which are found the metal contacts127against which the module connector's pins131connect, and an o-ring126surrounding the connector tongue128. When the module connector104is inserted into the MDS' connector103, the connector shield129fits into the recessed space126and squeezes against the o-ring121thereby ensuring a water-proof seal of the electrical connections between the MDS connector's metal contacts127and the module connector's pins131. The module connector104itself has a recessed space130for the MDS connector's tongue128to fit into as the connectors are inserted into one another. The MDS connector103may additionally have a single or several metal contact points (not shown) for the connector shield129to come into contact with in order to put the MDS' and the module's grounds in common. Another o-ring (not shown) may be used at the base of the shield129in addition to or in replacement of the initial o-ring121to seal the shield's129contact with the MDS connector103.

In this embodiment, both the MDS connector's103(male side) and the module connector's104(female side) parts have correspondingly round shapes at both ends in order to ensure a proper o-ring126seal since o-rings require round shapes to provide a proper seal.FIG. 12shows the connectors to have28contact points for illustration purposes. Any number of contact points, including only a handful, can be used instead of the 28-pin-based connectors shown and other shapes and connection specifications could be used instead of those presented without departing from the teachings of the present disclosure. It may, in fact, be beneficial to use existing buses and connectors such as those provided by the USB specifications to facilitate the development of both the MDS and modules. For instance, it would be possible to create a custom connector that relies partly, or even entirely, on USB signals between the module and the MDS in a water-resistant configuration. Water resistance is important in the case of the connection between the MDS and the module given that the module will be worn on the wrist and could be subjected to the user's own human sweat and/or contact with water as the user goes about their daily activities and/or routines. That's especially true in the case of some modules whose specific purpose may be fitness tracking or providing diving computer capabilities.

FIG. 13illustrates a cross-section of one of the embodiments of the electrical connectors from both the module102and the MDS101.FIG. 13 (a)illustrates the connectors before they are connected andFIG. 13 (b)illustrates the connectors once they are connected. The MDS connector recessed space126is shown as providing enough space for the module connector shield129to fit inside it. The MDS connector tongue128is shown as protruding slightly from the side of the MDS101. This is to permit easy replacement of the o-ring121by the user.FIG. 14shows a configuration where the tongue128is practically flush with the MDS'101body. The o-ring121in that configuration is harder to service as it is hidden inside the MDS' connector recessed space126. Either way, the o-ring121surrounding the tongue128finds itself compressed between the tongue128and the module connector shield129once the tongue128is fitted into the module connector recessed space130and the module connector shield129is fitted into the MDS connector recessed space126. This embodiment's module connector pins131are spring-loaded and can effectively be seen as what is typically-called “pogo-pins”. Hence, once the metal connectors127come into contact with the module connector pins131, the pins131start retracting and remain in some compressed form once the connectors are attached together as seen inFIG. 13(b). By using some form of spring-loaded pins, the module's pins131and the MDS connector's metal contacts127continue pushing against each other, and therefore remain connected, as long as the module102is connected to the MDS101.

Several changes and enhancements may be made to the connectors presented without departing from the teachings of the present disclosure. The spring-loaded pins may in fact be in the MDS' connector instead of the module's, and the metal contacts in the module's connector instead of the MDS'. Instead of using spring-loaded pins and metal contacts, for instance, other electrical mating connector types may be used, possibly inspired by or derived from existing connectors such as USB, D-subminiature, registered jack, DIN, slot/edge or any other connector technology on the market. Additionally, one of the mechanical locking mechanisms presented earlier may be integrated and/or combined to the electrical connectors.

FIG. 15illustrates a module-charging station179as a flip-cover box.FIG. 15 (a)shows a top-view of the charging station179with slots175for holding 9 individual modules. Each slot175has connectors similar to those found in the MDS embodiment shown inFIG. 1and allows connecting a module for recharging. A battery gauge177above each slot175enables the user to know the charging state of each module. A release button178at the bottom of the connector enables the user to release the module at any time.FIG. 15 (b)shows a side-view of the box179with its flip-cover along with the wall adapter180used to connect the box179for recharging to an electrical outlet. The wall adapter180may be connected to the box179through a power connector176at the back of the box179. The box179may double as a carrying case or travel accessory for carrying modules around by the user. The specific mechanical form-factor, number of slots, and type of connection to an electrical outlet may vary greatly without departing from the teachings of the present disclosure. The recharging station179may, for instance, itself have a battery allowing it to be recharged independently and later charging modules on-the-go.

FIG. 16illustrates a simplified block diagram one of the preferred embodiments of the present disclosure. As is shown, the MDS301is preferably, but not necessarily, composed of a backend303and a frontend304. The frontend304is primarily responsible for the basic watch-related functionalities such as keeping track of time, showing it to the user and providing functions such as date, alarm and stopwatch. In short, the frontend304provides the functionality typically associated with a conventional “non-smart” watch. The backend303is primarily responsible for all computerized capabilities more commonly associated with smartwatches. Preferably, but not necessarily, the backend303remains inactive, dormant or un-booted until a module302is plugged into the MDS301. When a module302is connected to the MDS301, the backend303becomes active, wakes up or boots in order to interact305,306with both the module302and the frontend304to provide the “smart” functionalities associated with then just plugged-in module302. Once a module302is disconnected from the MDS301, the backend303returns to its dormant or inactive state or shuts down. There may also be interaction307between the module302and the frontend304. Such may be the case for interactions right before the backend303is activated or for some key interactions that must bypass the backend303during normal operation. The MDS301and module302inFIG. 16may be the same MDS101and module102presented inFIG. 1, or they may be based on other form-factors, designs and connector technology.

FIG. 17illustrates an alternate simplified block diagram where the backend303is found in the module302instead of being in the MDS301. In this specific case, it's assumed the module302is preferably, but not necessarily, a portable device that can be worn on the wrist by a user in the case of modules102physically-connected to a MDS101or on the user's person in the case or remotely-connectable modules, and not just a fixed computer such as a PC. This, though, does not preclude the module302from itself being connectable to a computer in addition to being connectable to an MDS301. Otherwise, each system component operates in a similar fashion as when the backend303is included in the MDS301instead of the module302.

FIG. 18illustrates an embodiment wherein the module302attaches to a MDS308that operates as a regular smartwatch regardless of whether a module302is attached or not. As such, an MDS308does not necessarily need to have a dual mode of operation as explained in the previous embodiment with a frontend and a backend. Instead, all computing and peripheral capabilities and functions may be embodied in hardware and software very similar to existing smartwatches already found in the market.

FIG. 19provides a more detailed block diagram where each of the three main components, namely the backend303, the frontend304and the module302, each have a corresponding hardware314,315,313and software block311,312,310. The hardware blocks313,314,315are connected316,317together and the software blocks310,311,312rely on the hardware connections316,317to establish their own communication paths and channels318,319. Any number of hardware connection types, buses, techniques and technologies can be used to link components together and any number of software communication protocols and/or mechanisms and bus technologies can be used without departing from the teachings of the present disclosure. Hardware communication mechanisms may include, but are not limited to, USB,120, SRI, UART, PCI, SDIO, any common bus used in industry to connect hardware blocks or a custom bus. Software communication mechanisms may include, but are not limited to, sockets, pipes, fifos, ttys, memory-mapped address spaces, inter-processor interrupts, remote-method invocation, serial protocols, modem-like protocols, any other common software communication mechanism or even a custom mechanism.

Note that some system blocks may be hardware-only. The module302and frontend312could, in fact, contain nothing but hardware components without requiring any corresponding module software310or frontend software312. Note additionally that, as in previously shown figures, all hardware connections between the MDS301and the module302are carried over connectable electrical connectors such as, but not limited to, those presented previously. Hence, the arrows linking hardware blocks between the module302and MDS301presented throughout this disclosure should be viewed as potentially being a collection of several individual connection lines which provide bus and power capabilities among other potential uses. The same also applies for any internal links between hardware blocks or sub-blocks within the module302and the MDS301.

FIG. 20illustrates a block diagram with hardware and software of the alternate configuration illustrated in previously inFIG. 17where the backend303is in the module302instead of being in the MDS301. Much like in that previously-illustrated figure, the roles of each block and their interactions are the same as in the case where the backend303is in the MDS301instead of in the module302.

FIG. 21illustrates the entire set of communication channels that can possibly occur among the hardware and software blocks. In addition to the previously-shown interactions, this figure further illustrates that software from one block may in fact interact with hardware from any other block321,322,323instead of just a corresponding software block. In addition, the potential interactions320between the module's blocks and the frontend's blocks are illustrated. As previously-mentioned, there are cases where such direct interaction, without the mediation of the backend blocks, may be desirable or necessary.

FIG. 22illustrates a block diagram with hardware and software of the alternate embodiment illustrated in previously inFIG. 18where an MDS308operates as a regular smartwatch regardless of whether a module302is attached or not. In this case, the module's hardware313and software310interact the corresponding hardware325and software324of the MDS308without necessary distinction between backend and frontend abstractions or blocks.

FIG. 23provides a more detailed view of the hardware block diagram of one of the embodiments of the MDS301. In this embodiment, each overall block has a corresponding processing block connected to some specific hardware blocks. The frontend hardware315, for instance, comprises at least a frontend processing block (FPB)335powered by a frontend battery338and connected to the watch's display336and buttons337; those may be the same display122and buttons108,109,110,105,106as those presented inFIG. 1. The frontend battery338is preferably, but not necessarily, separate from any other battery and its primary function is to provide power to all frontend hardware. The FPB335is connected to the backend processing block (BPB)333through any technique or bus commonly used in industry, such as one of the previously-mentioned mechanisms. The FPB335is therefore responsible for processing display requests made by the BPB333and forwarding button input or other user input to the BPB333. The backend hardware314comprises at least the BPB333and its associated peripherals334. As previously-mentioned, the backend may be inactive until a module is connected to the MDS. As such, the backend's components333,334may be made to draw power from the module battery332found in the module, therefore avoiding the backend from utilizing the frontend's battery338. This, though, does not preclude the BPB333from having its own power-source in addition to or instead of other power sources. The module hardware313comprises at least the module processing block (MPB)331and typically, but not necessarily, associated module peripherals330. It may additionally, but not necessarily, include a module battery332which, as mentioned earlier, may serve to power the backend hardware314.

Note that while battery components and/or blocks shown or illustrated throughout this disclosure are shown to be explicitly connected to some specific blocks, such as their corresponding processing blocks or chips, all power-requiring components or blocks are assumed to be connected to a proper power source, even if such a connection is neither implied nor explicit.

FIG. 24illustrates another embodiment's hardware block diagrams, this time with the backend including a backup power source340. This backup power source340may be used to power the backend as the module302is being removed from the MDS301, for instance. The backup power source340may be a regular rechargeable battery or it could be a supercapacitor or any other kind of power source capable of holding enough power for the backend hardware to operate for a short period of time. This backup power source340may be usable by the backend in a number of circumstances. Namely, it could be used to power the backend, possibly for a short period of time, even if no battery-equipped module is connected. It could also be used as an alternate power source in the immediate aftermath of a battery-equipped module302being disconnected from the MDS301, thereby enabling the BPB333to have just enough time to properly or gracefully shut down and/or suspend before loosing power.

FIG. 25illustrates the alternate hardware block diagram corresponding to the simplified block diagram for an alternate system configuration where the backend is included in the module as illustrated inFIG. 17andFIG. 20. Note that in such a configuration, the MPB331and the BPB333may be packaged as a single unit such as in an SoC and there may be a single peripherals blocks that includes what is illustrated as separated module peripherals330and backend peripherals334.

FIG. 26illustrates a hardware block diagram where the BPB333is included in the FPB335. In this case, the FPB's role remains the same as in previous configurations and it is not capable of providing the level of computerized capabilities provided by the BPB333until the latter comes online once a module302is connected to the MDS301. The FPB335may also be included in the BPB333instead, or both may be combined together into a single block. It may be, for instance, that the FPB335and the BPB333are packaged as a single chip which is capable of providing both basic very low-pow capabilities sufficient for maintaining watch-like capabilities over a long period of time and advanced computerized capabilities sufficient for conventional smartwatch-like functionality. In that case, the computerized capabilities could remain partially or entirely unavailable until a module302is attached to the MDS301. Such configurations are possible with technologies such as ARM's™ BigLITTLE technology.

FIG. 27illustrates a hardware block diagram of the alternate embodiment illustrated in previously inFIGS. 18 and 22where an MDS308operates as a regular smartwatch regardless of whether a module302is attached or not. In such a case, the MDS308would typically comprise a single processing block341, a single set of peripherals343and single battery342.

FIG. 28provides a detailed view of one of the preferred embodiments of the BPB333hardware. The BPB333typically, but not necessarily, includes a backend processing unit (BPU)350to which are connected RAM352, persistent storage353(such as eMMC, raw NOR or NAND flash, an SD card or any other means for persistent storage) and a power-management IC (PMIC)351. In this example embodiment, the PMIC351is powered by the module battery332and itself controls power for the BPU350. Other configurations are possible as well. The BPU350is connected to the MPB331using one of the bus technologies mentioned earlier. The BPU350would typically, but not necessarily, be a System-on-Chip (SoC) such as one of those used in existing conventional smartwatches or smartphones from vendors such as, but not limited to, Qualcomm, Intel, MediaTek, TI or STmicroelectronics. The entire, or large parts of the, BPB333may also be a System-in-Package (SiP) instead of individual discrete parts. The BPU350could also be based on a powerful micro-controller unit (MCU) instead of an SoC.

As mentioned previously, the bus and power connections between the BPB350and a module would be provided through electrical connectors such as those detailed earlier once a module is connected to the MDS. The connection between the BPU350and the FPB335may also be provided by one of the previously-mentioned bus technologies. Unlike the connection between the BPU350and the MPB331, the link between the BPU350and the FPB335is likely fixed at factory time when the MDS is assembled and made using either a set of traces on a PCB, if the BPB333and the FPB335are found on the same PCB, or carried over using an appropriate connector technology between the PCB holding the BPB333and the PCB holding the FPB335, such as, but not limited to, FPC, FFC, conventional wires, board-to-board connectors and/or PCB-to-PCB soldering.

In addition to likely storing backend software and data, the backend storage may be used to store module-specific software (MSS) and module-specific data (MSD). MSS may include software to be run on the module itself such as module firmware (MFW), but it may also include backend module software (BMS) and frontend module software (FMS). BMS would be software that runs on the backend when its corresponding module is attached and FMS would be software that runs on the frontend when its corresponding module is attached. The collection of software and/or data and/or resources, etc. required to operate a module once it is connected to the MDS could be distributed separately or packaged together as a single set of assets in a single file, possibly a module assets package (MAP), and distributed in a number of different ways. Such components, be they distributed together or separately, may be retrieved by:

Loading from the module
Downloading at module attachment from a source in the cloud
Downloading at module purchase
Manually installing by the user
Shipping from factory on the backend storage
Using any other technological means for this purpose
Each system block would be provided with the required software to properly operate in the relevant circumstances using commonly-established software practices.

MSD would include data created at runtime during the attachment of a module and could be shared with the user's smartphone and/or PC and/or some relevant cloud-based infrastructure. In the case of a fitness module, for instance, the backend's storage could be used to record fitness information while the fitness module is operating, possibly by fitness-module-specific BMS running on the backend. The fitness data could then be sync'ed over a network connection when a network-capable module is connected or, if the backend includes networking capabilities, periodically while the fitness module is connected to the MDS. Modules may also share access to MSD stored in the backend storage. MFW, for instance, may request access to other modules' data and/or user-specific data in order to perform its specific functions.

FIG. 29illustrates another preferred embodiment of the backend and its blocks. In this case, the BPB333further comprises a supercapacitor354attached to the PMIC351to act as a backup power source340for the purposes outlined earlier. Additionally, backend peripherals334such as a vibrating motor355and networking hardware356are shown. Other backend peripherals334may include ay peripherals typically found in conventional smartwatches. The vibrating motor355may be used in the context of notification modules, for instance, to physically alert a user when a new notification is received. Some networking hardware356may include, but is not limited, Bluetooth and Wifi. Instead of each module providing its own Bluetooth capability for mating with a user's smartphone or computer, and therefore requiring each module to be paired individually, the backend may provide Bluetooth hardware for use in the context of any module connected to the MDS, thereby requiring a single pairing sequence with the user's other devices regardless of which module is plugged into the MDS.

FIG. 30illustrates a detailed view one of the preferred embodiments of the FPB335. The FPB335typically, but not necessarily, comprises a frontend processing unit (FPU)360—not to be confused with the sometimes common use of FPU to designate a “floating point unit”—to which are connected RAM361, persistent storage362(such as eMMC, raw NOR or NAND flash, an SD card or any other means for persistent storage), a battery338, the watch's display336and the watch's buttons and other inputs337; those may be the same display112and buttons and inputs108,109,110,105,106as illustrated inFIG. 1. To ensure better time accuracy, an external crystal and/or oscillator363may be connected to the FPU360instead of relying on internal silicon-based timing such as provided by PLLs. The external crystal363is not however required, and the FPU's360internal PLLs or clocks may be used instead. The FPU360is connectable to the BPB333using one of the bus technologies mentioned earlier. The FPU360would typically, but not necessarily, be an MCU such as one of those used in a very wide range of devices and available from several vendors such as, but not limited to, STmicroelectronics, Atmel, Microchip, NXP, TI, and many others. The entirety of the parts of the FPB360may in fact be comprised in an all-encompassing MCU IC. The FPU360may however still be a full SoC such as one of those in conventional smartwartches.

As in the case of the BPU, the storage362attached to the FPU360may serve a number of different purposes. In addition to storing FPB-related software and data, it may also include MSS and MSD for use by in the frontend's context.

FIG. 31illustrates another preferred embodiment of the frontend and its blocks. In this embodiment, there is an additional regulator364in the FPB335in order to ensure a proper power supply to the FPU360from the frontend battery338. Additionally, two peripherals are attached to the FPU, namely a piezoelectric buzzer367and a cryptographic chip366. The piezoelectric buzzer367may be used to provide conventional watch beeping functionality such as for alarms. The cryptographic chip366may be used for security-related capabilities and enhancements. Such a cryptographic chip366may be attached to the BPB's333SoC as well or, more commonly, such an SoC may itself include security and cryptographic functionality.

By having a separate battery338for the frontend and given that the FPU360is typically an MCU, it's possible to design a frontend that can operate for a prolonged period of time without requiring battery replacement or recharging. Indeed, some of the MCUs on the market can run for months or years on single coin-cell batteries. In fact, the entirety of the frontend could likely be replaced by the hardware used inside an existing classic, “non-smart” digital watch, many of which on the market can run for years without requiring replacing or recharging their batteries.

FIG. 32illustrates an embodiment of an MDS308wherein the MDS308operates as a regular smartwatch whether a module is attached to it or not, such as presented earlier inFIGS. 18, 22, and 27. In this case, the MDS208includes a SoC-based processing unit370connected to RAM371, storage372, networking hardware375, general I/O376, and a PMIC373, which is itself connected to a battery374. In this case, the MPB331is connected to the MDS308over one of the buses discussed earlier and the module battery332may provide power to the MDS308as additional or backup power. The design and operation of such an MDS308is fairly close to that of a current-day smartwatch except for the added ability to be connected to modules and the fact that module insertion triggers module-related or module-specific functionality and/or user interfaces on the smartwatch.

FIG. 33illustrates one of the preferred embodiments of the MPB331. Typically, but not necessarily, the MPB331includes an MCU383and its associated RAM381and persistent storage382(such as eMMC, raw NOR or NAND flash, an SD card or any other means for persistent storage). The MCU383may or may not be the same as one used for the FPU. Either way there is no requirement for them be similar or different. As in the case of the FPB, the entirety of the MPB331may be comprised inside a single MCU instead of requiring additional externals ICs such as for RAM381and storage382. The MCU is connected to the module peripherals330, if there are any, and the module battery332. The MCU is also connectable to the BPB333using one of the bus technologies described earlier.

As in the case of the BPB333and the FPB, the module's storage382may be used to store data and software. It's also possible, though not required, that a module may need firmware to be loaded from the MDS in order to start operating normally.

FIG. 34illustrates an alternate preferred embodiment of the MPB331where a bus converter IC331is used to convert traffic between the BPB333and the MCU. Such would be the case of a chip converting, for example, USB traffic on the BPB333side to FIFO/UART traffic on the MCU side, and vice-versa. Other bus conversion chips for other types of buses could also be used.

FIG. 35illustrates an example of the attachment sequence for a module. When the module is plugged into one of the embodiments of the MDS401, both the module and the backend become active402,403. This may be caused using hardware means wherein the module battery's power is supplied to both the MPB and the BPB as soon as a contact between the electrical connectors of the module and the MDS is detected. In other words, in one embodiment the module and the backend would be automatically powered as soon as an electrical connection exists between the MDS and the module. It could also be possible for the frontend to be notified when a module is effectively plugged into the MDS. The frontend would then have software that would be triggered and that would itself trigger the activation of the module and the backend by instructing hardware under its control to supply power accordingly or to trigger the resumption of saved state. In this case, the activation of the backend and the module would be under the frontend's control. The benefit of this type of software-controlled activation is that it could be changed or modified using software updates or user-selectable options whereas a hardware-controlled activation or power sequence is likely to be fixed at design time. The specific transition from inactive to active could require a full boot, a resumption from stored state or a wake from suspended state in RAM, the latter requiring some form of continuous power to refresh the RAM's contents. The specific mechanism can vary without departing from the teachings of the present disclosure.

Once the backend is active, it notifies the frontend of its state404. This then notifies the frontend that the backend is ready for two-way communication. Even if the backend activation is triggered by the frontend, the backend may require some time before it can start communicating with the frontend, hence the need for the backend to notify the frontend when it is ready. Once this is done, either the frontend or the backend notify the user that the backend is online406. This may be done using any number of different ways, including, but not limited to, lighting up LEDs, activating the LCD backlight, using the piezoelectric buzzer, activating the vibrator motor, or any combination of the above.

Once both the backend and the module are active and a connection is established between them405, they use whatever handshaking mechanism that is appropriate for the bus technology linking them together407to establish a communication channel and/or mechanism, identify the module, possibly load firmware for the module, and possibly start module-specific BMS. Finally, the backend and the frontend communicate408to inform the user that the module is now active and/or online, possibly load and/or start module-specific FMS, and possibly start displaying module-specific information onto the MDS display. The module would then be ready for use by the user through the MDS409.

Note that some of the tasks described as being serialized could be run in parallel and some tasks could be conducted in a different order while achieving the same result. Additionally, some tasks may be added and/or removed without departing from the teachings of the present disclosure.

FIG. 36illustrates an example generic information flow across the system's main blocks. In this example, there is FMS501for the module302running on the frontend304and BMS502for the module302running on the backend303. The module302may also itself have some software running such as MFW. On the top of the diagram, we can see the flow towards the module and at the bottom the flow from the module.

If a button is pressed by the user, for instance, it may be handled by the module's302FMS501. Given that the FMS501would handle module-specific interaction, the button presses or user input may be used to allow the user to navigate user menus and basic information display directly from within the FMS501without requiring any further interaction between the FMS501and the backend303. In that case, the FMS501would simply modify the display according to the user's input. In the case where the user's request requires more advanced assistance or requires access to information the frontend304does not have access to or involves making requests to the module302or any other case where the request cannot be processed within the frontend304, the latter would forward and/or convert the request into a command and/or data to be sent to the backend303. Much like in the FMS'501case, the BMS502would attempt to handle such requests in as much as possible and respond back to the frontend304, or forward and/or convert those requests it cannot handle into commands and/or data to the module302. If the user is attempting to retrieve historical data, such as consulting the fitness log for a fitness tracking module or historical glucose levels for a glucometer module, this data may be available in the backend's303storage. If the user is attempting to modify the way the module302operates, say, for instance, how often updates should be made for a GPS module or which access point to connect to for a wifi-capable module, this is probably a request that would then need to be forwarded to the module302by the backend303for further processing.

Conversely, the module302responds to MDS requests, continuously provides data to the MDS based on its configuration and/or sends triggers to the MDS based on key events. The BMS502then processes the module-generate responses, information and/or triggers and possibly forwards them to the FMS501for further processing and/or display to the user.

Note that the set of commands and data sent between blocks on the top flow are not necessarily equivalent. Even if the arrows are labeled identically between the frontend304and the backend303, and between the backend303and the module302, the set of commands and data shared between the blocks can and is likely to be vastly different. For example, a command from the frontend304to the backend303does not necessarily translate into a command or the same command or commands between the backend303and the module304. The same applies to all other arrow labels in the rest of the diagram.

FIG. 37illustrates another example information flow across the main system blocks. In this case, the frontend304does not include any FMS501. Instead, the frontend304essentially acts as a conduit for the BMS303. All user actions are forwarded by the frontend304to the backend303for processing as-is, and backend303display requests are sent back to the frontend304for display. It's entirely possible for modules302to have no corresponding custom software running on either the backend303or the frontend304. Instead, it's possible that modules may belong to known device classes, such as in the USB standard, where their operation is standardized and therefore does not require module-specific software. Rather, the backend303and/or the frontend304would have software for servicing specific module classes. A heart-rate monitor class would, for instance, allow all modules performing heart-rate monitoring to operate in the same way with the MDS regardless of the vendor and/or product variant to which a given module belongs to and without requiring any module-specific software other than support for heart-rate monitor class-type devices by the MDS.

In general, the roles of the FMS with regards to its corresponding module could possibly include at least of one of the following:

Basic interaction (ex.: display change)
Basic processing (ex.: change math ratios)
Display and handling of module-specific menus
Minimal storage

In general, the roles of the BMS with regards to its corresponding module could possibly include at least one of the following:

Complex interaction
Complex processing
Cloud interaction
Rich OS services
Large storage
Direct communication with module

In general, the roles of the MFW could possibly include at least one of the following:

Set up and operate the module peripherals
Managing the communication with the MDS
Manage the power and charging of the module battery

More specifically, in the case of a fitness tracking module, the MFW could likely be used to:

Set up sensors such as accelerometer, gyroscope and GPS
Manage sensors
Send sensor data to backend

Also in the case of a fitness tracking module, the BMS would likely perform at least one of the following:

Receive sensor data from the module
Process sensor data to retrieve meaningful user data (steps, heartbeat, distance, path, etc.)
Possibly use other data than from the module, like additional MDS-available data such as from backend peripherals, data available over the network, etc., to enhance/interpret new module data
Further analyze and store data in the background
Send distilled data for display by the frontend
Receive user interaction from the frontend
Process user interaction and send back status/data to the frontend for displaying and/or communicate with module to service user interaction/requests
Sync with smartphone and/or computer and/or cloud and/or internet of things (IoT) devices and/or other MDSes to share/process data, fulfill user requests, etc.

Additionally in the case of a fitness tracking module, the FMS would likely perform at least one of the following:

Receive, process and fulfill display requests for fitness information
Receive, partially process and/or forward user input (button presses, scrolling, swiping, etc.)
Provide basic fitness-tracking-specific menu capabilities

Aside from the module-specific software, the overall software stacks, if any, operating on the frontend, the backend, or the module, would be similar to that found on systems using similar hardware. Specifically:

the frontend being most likely an MCU, it would either rely on a real-time operating system (RTOS), an embedded operating system or a custom-made software stack, possibly based on what is commonly-referred to as a “while1 loop”, or a “bare metal” library,
the backend being most likely an SoC, it would likely rely on a high-level operating system (HLOS) such as Linux, Windows, one of Apple's OSes, FreeBSD or any other HLOS, including any of their variants such as, in the case of Linux for example, one of, but not limited to, the variants or derivatives of Android, Yocto, Buildroot, Ubuntu, or even a custom Linux distribution,
the module being most likely an MCU, it would have a similar choice of software as the frontend.

In the case of the frontend, the software stack would typically, but not necessarily:

Display to LCD

Store and retrieve data and/or software from the frontend storage
Control and be aware of backend and/or module states: boot, shut down, suspend, etc.
Maintain time-keeping operations
Provide basic watch functionality such time, alarm, date, and stopwatch
Provide higher-level abstractions and application programming interfaces (APIs) both for internal use by the software stack operating on the frontend and for software developers writing FMSes for their modules to handle:
a) Communication with the backend and/or module
b) Time and time-related operations
c) Access frontend hardware

In the case of the module, the MFW's role, if any, was covered earlier and its specifics would depend on the module's role. Some of the observations regarding the frontend would likely also apply in the case of modules as they are likely to be based on MCUs as in the case of the frontend.

In the case of the backend, the software stack would typically, but not necessarily, depend on the capabilities of the HLOS being used. As HLOS capabilities are too vast to expand on in the present disclosure and are already well known in the industry, the assumption is that all features found in the HLOS being used could be of use within the context of the backend. One specific aspect that would be of special concern for HLOSes is the mechanisms and corresponding time requirements for all power-related operations such as, but not limited to, booting, shutting down, suspending, resuming, waking, and sleeping. The priorities would typically be: a) finding the optimal configuration for providing the user with very quick access to a module's functionality on insertion, and b) rapidly but safely deactivating the backend once a module is disconnected. As in the case of the frontend, APIs may be provided on the backend for facilitating the creation of BMSes by application developers. Those APIs may be existing ones already provided by the HLOS being used and/or new ones specifically developed in the context of the MDS.

Note that since the backend and the frontend do not typically, though not necessarily, share RAM or persistent storage, the preferred communication means between the two is some form of hardware-backed remote communication mechanism as explained earlier. Still, in some configurations it may be desirable for the backend and/or the frontend and/or the module to share some form of RAM and/or storage to facilitate communication between them.

FIG. 38illustrates an example of the detachment sequence for a module. The releasing of a module may be done in a number of different ways. In the simplest form, pressing the release buttons411causes the mechanical locking mechanism holding the module against the MDS to release the module. In that case, the module is immediately released without any notification to the rest of the system components. Each system component must then handle the release that just occurred gracefully and return to the state that it had prior to module insertion. Another possibility is for the pressing of the release buttons to cause an electrical notification to be sent to the relevant system components while they are still being depressed by the user but before the mechanical lock is released. Given the speed at which human fingers move, this would likely give enough time for the relevant power-management-handling components to conduct their operations before the module is physically detached from the MDS and the connection between the module and the backend is lost. This may be especially useful if the backend relies solely on the module battery for power and would immediately loose power on module removal. Finally, another possibility would be for the module release to be done through the MDS' user interface instead of using release buttons411. Or, the release buttons would be electrical button triggers instead of acting as mechanical releases411. In this way, the releasing would be entirely handled in software and would only occur once the software identifies that it's safe to release the module. Hardware mechanisms would then be included to allow the releasing of mechanical locks by software.

FIG. 39illustrates an example overall information flow between the frontend304, backend303and module302, and the other external components such as the user's computer380, their smartphone381, a cloud service382they rely on and possibly IoT devices383. Other external components may also include other MDSes worn by other users. Data, commands, requests, triggers, and any type of interaction may be exchanged through the backend303either in the context of a given module302or generally with regards to an account and/or identity held by the user with any external component380,381,382,383which could, itself, interact with other components still, all for providing the user with the appropriate functionality in the context of their use of the MDS.

FIG. 40, for example, illustrates the overall information flow for a fitness-tracking module. In this case, the module302sends sensor data which is then processed by the BMS502before it itself sends real-time fitness information to the frontend304. The BMS502may also use the backend storage353to store raw sensor data and/or process fitness information as well as synchronizing with external components380,381,382,383for the benefit of the user. If the user relies on a cloud service382to store and analyze their fitness information, the backend303could sync with that cloud service382to send new data to it and receive distilled information back such as goal achievement statuses.

In a similar fashion, over-the-air (OTA) updates and upgrades may be made available to any of the module302, backend303or frontend304using any number of external systems and/or components such as those just mentioned.

Several other enhancements are also possible without departing from the teachings of the present disclosure. Here are, in no specific order, a list of features, additions or modifications that could be made to the module-driven smartwatch:

An adapter may be provided to enable modules meant to be connected to MDSes to actually connect into computers and/or smartphones
Modules may be required to all have USB connectors in addition to connectors for connecting to MDSes. This could be used for charging and allowing connection to PCs, whether the module is connected to the MDS or not.
An interposing dongle could be provided for attaching between a module and the MDS for providing extra functionality such as a USB connector to connect both the module and the MDS to a PC while a module is connected to the MDS, if the module doesn't itself have a USB connector for instance, or it could be used for debugging capabilities, enabling module developers to more easily develop and/or debug their modules and or module-related software while being connected to a working MDS.

It will be understood that numerous modifications and changes in form and detail may be made to the embodiments of the presently disclosed electronic device and method. It is contemplated that numerous other configurations of the electronic device and method may be used, and the modules (“modules” as in “abstractions” or “blocks”, not as used earlier in this disclosure) of the electronic device and method may be selected from numerous modules other than those specifically disclosed. Therefore, the above description should not be construed as limiting the disclosed electronic device and method, but merely as exemplification of the various embodiments thereof. Those skilled in the art will envisioned numerous modifications within the scope of the present disclosure.