Method, processor circuit and computer program for operating at least one piece of application software in the processor circuit of a mobile terminal, and vital data monitoring

Abstract

The invention relates to a method for operating at least one piece of application software in a processor circuit of a mobile terminal, wherein a piece of framework software and the relevant application software therein are executed as an independent module in each case by a runtime environment of the processor circuit, and user interactions of each piece of application software with a user are executed via the framework software, wherein, as a result of the user interactions, graphic outputs of the application software are output to the user via the framework software, and / or user inputs from the user are received via the framework software and forwarded to the application software.

Description

[0001] Method, processor circuit and computer program for operating at least one application software in the processor circuit of a mobile terminal and vital data monitoring

[0002] DESCRIPTION:

[0003] The invention relates to a method for operating at least one piece of application software in a processor circuit of a mobile terminal. Such application software provides a function in the terminal that can be used directly by the user, such as health monitoring and / or media playback, to name just a few examples. For this purpose, the application software is executed in a runtime environment of the processor circuit, such as can be implemented, for example, by an operating system or a so-called container or a virtual machine. In the context of the present description, the runtime environment also includes, in particular, the window manager for the graphical user interface of the application software. A common term for application software is also app.The invention also includes the processor circuit and a computer program for implementing the method in a processor circuit as well as a mobile terminal with such a processor circuit.

[0004] Implementing one or more application software packages on a mobile device requires the full effort of implementing functionalities that may be common to all application software packages, such as a login for authentication and / or access to a device-external data storage in a stationary backend server, for example, on the Internet. To reduce implementation effort, multiple application software packages can be implemented in a single, comprehensive application software package or app, if all application software packages share a commonality that is understandable to the user, for example, if they originate from the same software manufacturer.However, when developing such a complete app, the software developers of each participating application software are tied to each other in such a way that during test runs and / or software extensions, all developers must provide a working version of their application software in order to obtain a correspondingly working version of the complete app. This increases the risk of a bug in the overall app. The need for coordination also impairs development efficiency.

[0005] CN 1 13 971 070 A discloses a method and system in which multiple virtual machines simultaneously display content on the same display.

[0006] The invention is based on the object of enabling efficient implementation and testing of at least one application software on a mobile terminal device.

[0007] The problem is solved by the subject matter of the independent patent claims. Advantageous further developments of the invention are described by the dependent patent claims, the following description, and the figure.

[0008] As one solution, the invention comprises a method for operating one or more application software packages in a processor circuit of a mobile device. For this purpose, a runtime environment of the processor circuit executes a framework software (frame app or stage app) and, as a respective module therein, the at least one application software package. The runtime environment here refers in particular to the operating system or a virtual machine containing the operating system or a container. The runtime environment thus executes the framework software, and in this framework software, the application software package is executed as a binary code module.The term "module" here means that this application software is independently integrated into the framework software. This means that there is no intrusion or use of one application software by another application software in the framework software, and the framework software interacts with the module exclusively via at least one predefined interface (API - Application Programming Interface). In particular, each module performs its own memory management. This means that the framework software has no access to the module's data storage areas and / or the module accesses content data from the framework software's data storage areas only by requesting it via an interface, which then transfers the content data to the module via the interface.

[0009] “The module is executed in the framework software” means that the respective application software is executed or operated as a running program within the framework software in one of several different ways. The application software can be executed in a so-called user space or address space independent of the framework software and / or as its own independent process in the runtime environment, so that the framework software and the respective application software each represent a separate process in the runtime environment. Alternatively, the application software can be integrated into the framework software by means of compilation and / or a linker and thus run in the same process and / or in the same user space (address space) in the runtime environment. The application software is in binary code (machine language), not as a script.

[0010] The framework software represents a framework or stage in relation to the respective application software in that user interactions in the respective application software with a user are carried out exclusively or partly via the framework software. There can be two types of “user interactions”. User actions result in graphical output from the application software being shown to the user on a screen and / or user inputs from the user being received via the application software. A screen of the mobile device or an operating device linked to the device can be used for the output. For example, a screen on a motor vehicle console can be used, which can be linked using the software product CarPlay® from Apple Inc.®, for example. The “operating device” in this case would be the infotainment system of a motor vehicle, for example.The user inputs can be received from a touch sensor of the screen, i.e. the screen can be a touchscreen.

[0011] To enable this to work with a standalone module (i.e., the application software) from the framework software, the framework software requests a screen output area from the operating system or, more generally, from the runtime environment for the currently active application software, and then transfers control of the screen output area from the framework software to the application software for user interactions. This has proven to be an advantageous solution with the iOS® operating system from Apple Inc.®. The screen output area can be made directly controllable or accessible to the application software as a so-called framebuffer and / or via a system call (syscalls) of the operating system, i.e., in particular, without any contribution from the framework software.The application software can thus define graphic content in the screen output area by setting pixel values ​​and / or executing drawing commands within the application software itself.

[0012] From the user's perspective, the combination of framework software and the application software integrated within it results in an overall app or user software in which the user can select and activate an application software within the framework software and then carry out their user interactions directly with the currently active or selected application software. However, the framework software is not simply a component of the operating system, such as a window manager, but rather is itself overall application software or user software executed in the runtime environment. This means that it is a process distinct from the operating system and executed by the operating system with its scheduler as a user process.

[0013] The invention provides the advantage that for such an overall app or user software with multiple integrated application software, the development of each of the application software can be carried out independently of any other application software, since during later operation or execution in the runtime environment for the respective application software there is no link to any other application software, so that to test an individual application software in the overall app, the framework software only needs to be executed in the runtime environment with the application software to be tested, without further application software having to be integrated. In this way, it can be individually tested for each individual application software whether the application software is functional. In this case, there is no dependency on any other application software and therefore no availability of other application software in the framework software is necessary.This allows the entire app to be tested step by step or individually with each application software as a standalone, independent module. This innovative organization of an entire app as a framework with application software integrated into it as independent modules enables the efficient implementation of application software on mobile devices.

[0014] The screen output area can be configured as a so-called view or framebuffer and / or made directly controllable or accessible to the application software via a system call (syscall) of the operating system, i.e., in particular, without any contribution from the framework software. The application software can thus define graphic content in the screen output area by setting pixel values ​​and / or executing drawing commands within the application software itself.

[0015] The invention also includes further developments which result in additional advantages.

[0016] A further development includes the application software providing a graphic control interface (e.g. as an API - Application Programming Interface) and the framework software calling this graphic control interface of the currently active application software to transfer control over the screen output area (to output graphic content to the screen output area). The respective application software is then designed as independently running software, the graphic output of which occurs exclusively via its graphic control interface and thus into the screen output area. In particular, a separate graphic user interface is output via the graphic control interface and / or a separate thread is operated by the application software and / or event handling is carried out for input events from the touch sensor system (Event - receiving a touch signal in the area of ​​the image output area, e.g.in the form of touch coordinates). Such event handling (processing user input) represents the area of ​​​​a software that, through the processor circuit, assigns a signal from an HMI hardware (HMI - Human-Machine Interface), for example the touch sensor of the touchscreen, to a function of the mobile device that is to be triggered based on this signal. This now takes place within the application software itself and not, as is usually the case, within the framework software, which would then call one of the modules. This results in a significant difference to a so-called plug-in for an entire app. A plug-in would simply provide a large number of individual functions as a dynamically linked function library, each of which would be called individually by the framework software if a corresponding event of a user action (e.g. clicking a button) were to occur in the event handling of the framework software.Here, the opposite is true: the application software is designed to run independently, i.e., it has or operates its own GUI and / or its own event handling. The application software can provide its own graphical user interface, i.e., it can have operating elements (e.g., buttons, sliders, an operating menu) independent of the framework software and can independently monitor their operation. This has the advantage that this application software can also be run without framework software, individually and independently of any other application software and independently of the framework software. Instead of the framework software, for example, a (rudimentarily designed) test environment can be coupled with the application software in order to be able to run the application software in a runtime environment during test operation (without framework software and other application software). The test software can, for example,How the framework software queries the screen output area of ​​the screen, for example from the operating system, and then the user interactions transfer control of the screen output area to the application software under test by calling the graphics control interface. Unlike framework software, however, the test software does not have the option of switching between different application software. Alternatively, each application software can be run on its own in a runtime environment (without any additional test software) using appropriate compile options, and user interactions can be tested automatically according to a predefined procedure, for example based on a script or unit testing. This means that when developing each individual application software, this can be done independently of any other application software and independently of the framework software.

[0017] According to a further development, the framework software provides or operates at least one common service function for each application software. Through such a service function, the respective application software provides input and / or output functionality for interaction with the runtime environment and / or authentication. Such input and / or output functionality can, for example, be access to a data storage device of a mobile device and / or a server on the Internet. This does not have to be programmed into the application software itself; instead, the service function of the framework software can be accessed.Likewise, in addition or alternatively, authentication regarding user authenticity and / or authorization and / or availability of a software license can be performed by the framework software as a service function, allowing the application software to be developed without such functionality. This enables synergy effects by outsourcing service functions to the framework software.

[0018] The at least one service function includes in particular one or more of the following:

[0019] • user authentication of the user,

[0020] • a storage service for storing and / or loading media data, for example MP3 or streaming,

[0021] • a connection to a Lambda infrastructure (for so-called serverless computing),

[0022] • a backend interface (for access to a backend server on the Internet),

[0023] • cloud access (to a cloud portal of the device or the user),

[0024] • reading of at least one sensor coupled to the processor circuit (for example a motion sensor and / or a receiver for a position signal of a GNSS (global navigation satellite system) and / or a heart rate sensor, for example a smartwatch),

[0025] • Coupling the application software with a vehicle interface (API - Application Programming Interface) for data exchange with the vehicle (e.g. vehicle sensors and / or vehicle screen). The framework software can therefore support any application software integrated as a module with these functionalities. This enables efficient design of application software because it no longer has to contain such service functions itself. When testing the application software as standalone software without the framework software, these service functions can be simulated, for example. So-called dummy functions without functionality but with fixed outputs or response data can be coupled to the application software in order to test the response of the application software.

[0026] According to a further development, several application software packages are integrated into the framework software as described, and the individual user interactions of the application software packages are then carried out via the shared framework software in parallel (simultaneously) or alternately (sequentially). For parallel execution, the available area for the graphical output of the application software packages can then be divided into one or more screens for each individual application software package.

[0027] In connection with the alternating execution of user interaction with only one application software at a time, a further development provides for the framework software to switch between application software in order to alternately link or provide at least one user interaction with one of the application software for the user. The user can thus switch between the application software within the framework software. For this purpose, switching can occur, for example, depending on a user input, to whom corresponding selection elements are provided in the framework software, for example a respective icon for each application software and / or an operating menu with the available application software. The framework software thus takes over scheduling, which would normally be carried out by the runtime environment in the case of independently executing application software in the runtime environment.

[0028] According to a further development, a uniform exchange protocol is used for each application software to exchange interaction data for user interactions (i.e., the output data of the graphical outputs of the individual application software and / or the input data of the user inputs, e.g., touch coordinates of a touchscreen). Each application software therefore interacts with the framework software via the same exchange protocol, which, from the perspective of the framework software, can display the graphical outputs and / or transfer the input data of the user inputs to the respectively active application software in a uniform or identical manner. The output data can, for example, define or describe a respective graphical user interface (GUI) of the respective application software.

[0029] As already explained, according to a further development, the respective application software and the framework software can be executed in a common user space or address space in the runtime environment as a common process. For this purpose, the application software can be linked into the framework software, for example, using a linker, whereby memory addresses for the program instructions of the application software can be reached or addressed from the framework software in the same address space, or a jump can be made to them using a program pointer. Alternatively, each application software and the framework software can be operated in separate address spaces as different processes in the runtime environment.Interaction between the framework software and the respective application software can then take place via interprocess communication (IPC), which can be based, for example, on a respective socket and / or shared memory. According to a further development, the application software can be compiled and / or linked into the framework software as a source code module. Alternatively, the application software can be linked to the framework software as a fully executable binary code module at runtime. If a shared address space is desired, this can be done using dynamic linking, for example, or, if the address spaces are separate, using the described IPC (Interprocess Communication). This results in appropriate memory organizations in the runtime environment to link each application software with the framework software.

[0030] According to a further development, the framework software provides a user interface for user interactions. In other words, this results in a uniform GUI for all application software within the framework software. In particular, replacing application software ensures that no changes in layout or appearance are made for the user of the framework software.

[0031] In order to provide a corresponding overall app or user software with the framework software and the application software integrated therein, the invention also includes a method for generating such user software. The method comprises the following steps:

[0032] • Creating an application software or several application software, each as independently executable software, which provides user interactions with a user during operation, for example an application software in the form of a health monitoring and / or a media player, to name just a few examples,

[0033] • Testing each application software individually, i.e., without the framework software and without the other application software. User interactions and / or service functions expected in the framework software can be simulated or simulated or specified using predefined response data (so-called unit tests).

[0034] • Providing a framework software that has a user interface for user interactions with the user (but which itself does not have an application function, i.e. a functionality that can be used by the user, such as health monitoring or media playback),

[0035] • Coupling the framework software with the respective application software to form the overall app or user software (this can be done in the known manner by compiling and / or linking or, in the case of ready-to-run application software as a binary module, by dynamic linking or interprocess communication,

[0036] • Operating this User Software in accordance with an execution of the method already described.

[0037] This method for creating user software allows the user software to be created efficiently because each application software can be developed independently of any other application software and any framework software, which reduces or eliminates the need for coordination and / or communication between the developers.

[0038] As already mentioned, the respective application software is, in particular, a health monitoring or health application for recording and / or evaluating the user's body signals, such as heart rate and / or body temperature. In addition to or as an alternative to body signals, the health application can also record the user's mood, for example, by surveying the user. This means that the user's well-being can be queried and also tracked or monitored over time.

[0039] For use cases or application situations that arise in the

[0040] Method and which are not explicitly described here, it can be provided that according to the method an error message and / or a request to enter user feedback is issued and / or a standard setting and / or a predetermined initial state is set.

[0041] As a further solution, the invention comprises a computer program corresponding to the method with the corresponding computer instructions, which, when executed by a processor circuit of a mobile terminal and / or a processor circuit of a stationary Internet server, cause this respective processor circuit, combined or individually, to carry out a method according to the invention. The processor circuit can thus be provided in a mobile terminal or in a server, or as a distributed processor circuit partially in the terminal and partially in the server.

[0042] Accordingly, the invention also encompasses such a processor circuit with an embodiment of the computer program.

[0043] Finally, the invention also encompasses a mobile device that has an embodiment of the described processor circuit. This is, in particular, a portable mobile device, such as a smartphone, a tablet PC, a smartwatch, or data glasses, to name just a few examples. However, an entertainment system (information entertainment system) of a motor vehicle can also be used as a mobile device.

[0044] Exemplary embodiments of the invention are described below. The single figure shows:

[0045] Fig. a schematic representation of an embodiment of the processor circuit according to the invention when carrying out an embodiment of the method according to the invention.

[0046] The exemplary embodiments explained below are preferred embodiments of the invention. In the exemplary embodiments, the described components of the embodiments each represent individual features of the invention that can be considered independently of one another, each of which also develops the invention independently of one another. Therefore, the disclosure is intended to encompass combinations of the features of the embodiments other than those shown. Furthermore, the described embodiments can also be supplemented by further features of the invention already described.

[0047] In the figures, the same reference symbols designate elements with the same function.

[0048] The figure shows a mobile device 10, which may be, for example, a smartphone, a tablet PC, or a smartwatch. The mobile device 10 may have a screen 11, which may also be configured as a touchscreen. Graphic outputs 12 from one or more user programs (application software) can be displayed on the screen 11. An example is shown of how the graphic output 14 from a user software 13 is displayed on the screen 11 and (only by way of example) the graphic output 15 of another software 16, which will be explained in more detail below.

[0049] The user software 13 and the additional software 16 can be executed by an operating system OS. The respective software and the operating system can be stored in a RAM of the mobile terminal 10 and executed by a processor circuit T. A respective display area 17, within which the respective user software 13 and software 16 output their graphical outputs 14, 15 on the screen 11, can be defined or controlled, for example, by a window manager or window manager WM, which is a separate software, separate from the software 13, 16.

[0050] In the user software 13, the special feature can be provided that the output area 17 can be divided into an output area 20 of a frame application RA and a screen output area 21 of an independent application software APP 1 integrated into the user software 13.

[0051] Another special feature is that via the output area 20 of the frame software RA, another independent application software APP2 can be selected, which can then output its graphic output in the screen output area 21 instead of the application software APP1.

[0052] The following explanation serves to illustrate the difference between the application software APP1 and APP2 in a simple, monolithic user software.

[0053] The user software 13 can have the framework application RA as a program component or program block for controlling the output area 20. The application software APP1, APP2 can be linked to the user software 13 as a respective module 22, for example as binary code using a linker with the framework application RA. When operating or executing the user software 13, the framework application RA and the respective application software APP1, APP2 can each be executed as at least one thread 23. The respective application software APP1, APP2 can exchange data via program interfaces 24, for example so-called APIs and / or (if the application software APP1, APP2 is executed separately in a different process than the framework application RA), via corresponding process communication, for example with the operating system OS, of the framework application RA.The framework application RA can, for example, provide service functions 25 for the application software APP1, APP2. Direct communication between the application software APP1, APP2 and the operating system OS can be achieved via so-called system calls or syscalls 26.

[0054] A special feature can be that a graphics output or graphics control interface 27 can be routed as an interface 24 within the user software 13 from the respective application software APP1, APP2 via the framework application RA, which in turn can communicate with the operating system OS via a graphics control interface 28 in order to thereby form or provide the output 14 with the output area 20 and the screen output area 21, the graphic content of which can be received from the application software APP1 via the graphics control interface 27. Thus, switching 29 between the outputs of the application software APP1, APP2 can take place within the framework application RA.

[0055] The application software APP1, APP2 can each be designed as independently executable software, which is illustrated in the figure by the software 16, which can be a copy or another instance of the application software APP1, but which can be compiled outside the user software, i.e., without the framework application RA, and linked to the independent software 16, so that its graphics control interface 27 can now be directly linked to the operating system OS, as was described with the interface 28 for the framework application RA. Instead of the direct link, the application software APP1 can be integrated into test software that does not provide for switching between application software and merely establishes the connection between the graphics control interface 27 and a screen output area in the operating system OS.

[0056] Output 15 of the standalone application software APP1 on screen 11 is displayed to the right of the output of the framework application RA. In this case, the respective service function 25 can be fed with empty data or pre-recorded dummy data, such as historical sensor data.

[0057] By reserving the screen output area 21 in the operating system OS and then transferring it to the currently activated application software APP1, e.g., via the graphics control interface 28, the framework application RA can define or control the graphics data for the operation of the screen 11 in the screen output area independently of the framework application RA. In general, the application software APP1 can thus be developed independently of the user software 13 and only subsequently combined with the framework application RA to form the user software 13.

[0058] Below are some aspects of the idea summarized:

[0059] The Stage app, as an application shell, contains app modules, one of which is health monitoring. A large framework (user software) is thus formed by several smaller application software modules, which are also intended to be stand-alone capable.

[0060] A master app or state app (stage application), i.e. the framework app (framework software), offers a "stage" (input-output management) with a user interface area and auxiliary functions (e.g. login). This "stage" then runs modules that are obtained as binary code from the store and loaded into the master app, or that are linked into the master app (using a linker) when the app is created.

[0061] It will be a structure with loadable or linkable function modules that do not just function passively as plug-in function collections, but have their own user space or are independently functional, i.e. can be compiled and executed without the master app.

[0062] The integrations described here are performed at the level of the overarching platform or framework software "Stage" (i.e., the master app). The module integrated within it, the actual application software, accesses the integrated system hardware via interfaces provided by the operating system or the master app. One component of the application software is, for example, an application for the smartwatch for monitoring biosensor measurement data, e.g., heart rate. If a smartwatch is available, the framework software with its integrated application software can be installed on the smartwatch. Monitoring the application software makes it possible to observe the heart rate live in real time or at short time intervals, if necessary.

[0063] The framework software, as well as modules of application software within the framework software, control the appearance on the smartphone and / or on the vehicle screen connected via a data connection. Control of the screen is assigned to a module (i.e., a currently active application software) or to the overall framework software itself by navigating the appropriate navigation within the framework software.

[0064] To use the application software, the framework software requests authorization upon startup. The user is prompted to log in to the authorization provider using their ID. Upon successful login, the framework software and its modules have access to an auth token that can identify the user and verify its validity with a provider (e.g., using an identity kit). The framework software provides logic that can renew the determined auth token. For this purpose, a backend provided by the framework software is used to determine a new auth token. The backend has the necessary permissions for this.

[0065] The application software module within the framework software preferentially loads content for display and playback in the application software from a connected backend. Access to the backend requires valid user authorization. For this purpose, the auth token provided during login is passed to the backend. From the backend, the application software module receives a list of the content available in the context of the requesting user, or a subset thereof, depending on the user's preselection (e.g., only content of a certain type or content that corresponds to a specific, previously assigned characteristic).

[0066] The approach of developing and / or operating one or more application software as modules within a framework software is referred to here as app-in-app because, for the user, the framework software appears as a single app, in which one or more application software is provided as modules for selection or activation. This app-in-app development enables work on the larger (mobile) overall app in a multi-team setup, where each team is responsible for a sub-area (of an application software) of the overall app, which can be considered a standalone app.

[0067] Collaborating with a larger development organization to deliver a single mobile app is otherwise a challenge in itself. The app would be logically and user-friendly divided into different functional areas, each covered by a single team. However, all teams would then need to integrate their results into a larger app to test the actual functionality and deliver it in a consumable form.

[0068] This isn't very efficient for the setup described. The standard setup would mean that all developers from all teams work on a single mobile app project in their development environment in the same version control repository, resulting in an exponentially growing number of integration requests to each of the other developers whenever one of them has a new contribution to make. However, this integration is necessary to test what has been achieved. A typical situation is that a developer contributes multiple times a day. This system is doomed to fail because the larger the team overall becomes, the less time each individual developer has to work on their assigned task, as they are busy tracking the changes everyone else is contributing.

[0069] The idea, therefore, is to provide a collaborative model in which each team's domain operates as a standalone app (application software) for testing purposes. The larger overall app, which incorporates all the team's results (all application software to be integrated), can incorporate the already tested application software as modules.

[0070] This structure reduces the integration effort for the entire development community by abstracting integration efforts at the team level.

[0071] This solution has the following advantages:

[0072] • Individual, independent assurance of the testability of each of the modules as independently executable application software for testing purposes;

[0073] • less integration effort for each developer, as only the contributions of local teammates need to be integrated and not those of the entire development organization of the overall app;

[0074] • more efficient development process and less time spent on integration.

[0075] The overall app defines a framework and protocol expected by each module (application software) to be implemented. Each module is defined as a package dependency that points to a specific version of the modules or a source code branch of them. The dependencies are resolved at build time (compiling and / or linking the software), so that the resulting app is a single, integrated mobile app. Each module can, for example, be defined as a so-called Swift package and can be located in its own source code repository.For example, in the same repository, there may be a so-called xcode workspace that hosts a standalone application for this module to run the module itself as a standalone application that serves the sole purpose of testing or simulating the model functionality of the application software independently without the framework software on a computer or on a connected mobile device.

[0076] To enable automation during compilation and / or linking for the Swift packages, the standalone application software, and the overall app at the integration level, a tool that provides automation pipelines for reuse based on the so-called Fastlane framework is preferred.

[0077] Overall, the examples show how an app-in-app development option (app - application software) can be provided.

[0078] The following are aspects of an idea related to health monitoring. They are considered an independent invention that can also be implemented independently of the described app-in-app solution:

[0079] During a journey, application software can record vital data of at least one vital parameter of a user as a health monitoring function, in particular a biosensor measurement (e.g., heart rate) and / or a psychological observation parameter (e.g., mood). The driver of the vehicle is observed as the user. The observed values ​​contained in the vital data can be stored together with a timestamp and / or a geolocation of their observation.

[0080] During and / or after a journey, a georeferenced representation of the observed values, e.g., by means of color coding for different numerical values, can be displayed to the user on a road map. It can be provided to use a filter (e.g., a correlation filter for predefined curve shapes or a gradient detector for determining a temporal gradient) and / or a threshold value comparison to detect at least one route section in which, in a temporal progression of the respective vital sign, an exceptional event defined by the filter and / or the threshold value or an exceptional state of the user defined by the filter and / or the threshold value, e.g., an increased pulse rate, is detected.

[0081] For example, the user can be questioned about such an exceptional event, e.g. by asking: "It seems you were stressed on Arnulfstrasse. What could be the reason for this?". Causal data can then be determined for the exceptional event, which indicates a cause or a potential cause of the exceptional event. The causal data can be determined using a user survey and / or a road traffic situation (e.g. a traffic jam or rush hour traffic) can be identified as the cause using traffic data and / or a route characteristic (e.g. city driving or winding road or driving through nature) can be identified as the cause using map data. An exceptional event can signal a deterioration or an improvement in the user's condition in relation to a training goal.

[0082] A countermeasure to avoid or mitigate the exceptional situation can be assigned to each exceptional event, e.g., via a look-up table or an artificial neural network. For example, for the exceptional event "increased heart rate," a countermeasure such as "increased ventilation" or "increased cooling" can be assigned. Other exemplary countermeasures could include playing music, adjusting the passenger seat, adjusting the lighting, or suggesting an exercise (e.g., for relaxation or to stimulate circulation). Thus, a countermeasure can be automatically triggered during the journey if the exceptional event is detected in real time.

[0083] In a further development, it is possible to determine whether a potential cause for an exceptional event exists for upcoming route sections, e.g., based on traffic data and / or map data. At least one countermeasure can be triggered for a detected cause before and / or upon reaching the respective route section. For example, as a countermeasure, ventilation can be increased as the vehicle approaches a traffic jam, allowing the user's body to be preconditioned for the traffic jam.

[0084] In order to offer a user a personalized lifestyle health offering (health monitoring functionality), health data (vital data) from a smartphone (e.g. vital data monitoring) can be determined by connecting to it, linking it with driving data and deriving recommendations for exercises. During the journey, the user can be automatically suggested various exercises (e.g. breathing exercises, reflection exercises) to perform in order to optimize their well-being for the journey towards an exercise goal that the user can specify at the start of the journey. After the journey, the user can view their driving and health data on the mobile application; there, preferred exercises (e.g. stretching exercises, relaxation exercises) for after the journey are suggested.Progress in achieving an exercise goal or exercise purpose can be monitored during and / or after the ride by evaluating vital data, and further exercises can be selected and suggested depending on a detected remaining discrepancy between vital data and exercise goal.

[0085] The application software is preferably networked with the user's data sources and, thanks to data-based monitoring, uses targeted opportunities to proactively promote the user's well-being (according to the exercise goal) during and after the trip through personalized services. The connection of health data to sensors and actuators in the vehicle also enables physical, situation-dependent solutions in the vehicle and / or the prevention, detection, and assistance of health emergencies.

[0086] The overall system, which can be controlled by the application software, preferably consists of the following components:

[0087] • The application software is implemented as a module for a framework software: o with functionality for reading the heart rate transmitted by a smartwatch, o with functionality for reading the API provided by the operating system of a portable mobile device for determining GPS coordinates and movement speed,

[0088] • the framework software, into which the application software is integrated merely as a module, provides the following service functions in particular: o with smartwatch connection, o connection to a console screen of the motor vehicle,

[0089] • Backend server for media content (e.g. training videos) for the application software:

[0090] ■ with File System Service for storing media and / or ■ with Serverless Code Execution Infrastructure (Lambda) for executing business and integration logic in the backend and / or

[0091] ■ with API Gateway service to offer the backend interfaces via the public Internet and / or

[0092] ■ with CloudFront service to secure temporarily and individually made available content, and / or

[0093] ■ with a hosted-zone configuration for a domain with subdomains for

[0094] • development (software development)

[0095] • staging (production operation)

[0096] When the user connects their smartphone or portable mobile device to the vehicle via a connection such as Apple® CarPlay® (wireless or wired), the app's user interface (application software) is available on the vehicle's console screen. The app's home screen may offer the option to answer a check-in question, asking whether the user is feeling well or not. The answer, along with the date and time, is saved in the app's local memory on the device, allowing it to be displayed at various locations on the app's screen.

[0097] Check-in question about the exercise goal: 'How would you like to arrive?' User response options: "More alert," "More relaxed," "Happier" (exercise goal)

[0098] Based on the answer to the check-in question, the trip is optimized for the user to achieve the exercise goal. Based on the user's answer, exercises are selected and recommended for the trip. For example, the user can choose between three modes: "More Alert," "More Relaxed," and "Happier." Based on the check-in question, three exercise recommendations can be issued for each trip. By performing the exercises, the user should achieve or get closer to the state of mind determined by the check-in question.

[0099] For example, the user can select three health data points (vital indicators) that are important for their driving fitness. After selecting the three data points, the user can set a goal for each data point that they want to achieve in order to feel comfortable. When the user starts a ride, they can see the current vital signs on the console screen.

[0100] The goal of "Driving Fitness" is to sensitize the user to their current health status before driving. The color scheme (green, yellow, red) of the recorded vital signs does not necessarily have a medical indication. The color scheme is intended solely to indicate the deviation from the individual goals set by the user. Experts can determine the degree of deviation that requires which color scheme to be used in simple experiments with test subjects.

[0101] A media library can be provided so that users can find and select specific content, and / or media content can be available for exercises and / or automated user environment design (e.g., nature sounds). Each piece of content belongs to a format category—for example, there are four: mood makers, breathing exercises, soundscapes, and coaching.

[0102] Media content can be displayed for different moods, e.g. a certain breathing exercise can be beneficial for two different moods, e.g. three moods: "More alert", "More relaxed" and "Happier".

[0103] Each exercise or piece of media content belongs to a specific "content format," e.g., "breathing exercises," "break fillers," or "coaching sessions." Depending on its nature, an exercise can be presented in different mood categories.

[0104] The selection of exercises varies depending on the user’s health data (vital data).

[0105] Displaying and / or analyzing vital data raises the user's awareness that the user's health status may change during the ride.

[0106] To this end, the application software uses the described connection of the smartwatch to a road map to track at least one trip for the user. To track the trip, the user must manually start and stop the trip recording. After the trip, the color-coded route and insights into health data (= heart rate) about the trip can be displayed. Using the filter and / or threshold, the user can be shown whether, for example, the heart rate or general vital data has increased or decreased during the trip (based on the user's average measured heart rate). In other words, the filter and / or threshold can be set relative to the user's average vital data.

[0107] The user can be given more detailed information about the trip and an exercise recommendation based on the check-out question in order to avoid the exceptional events or (in the case of positive developments) to reinforce them.

[0108] One aspect is to raise awareness that the user's health status may change during a ride by displaying heart rate changes at the end of a ride.

[0109] Based on changes in health data during the ride, a check-out question can be provided. The check-out question can be answered on the console screen or on the device. The purpose of a check-out question at the end of the ride is to give the user the opportunity to reflect on their ride and determine, for example, whether the exercises have had any effect.

[0110] This allows the user to set their individual driving fitness goal. By allowing the user to set a training goal for vital signs, a driving fitness score can be displayed, meaning that the comparison of the actual value to the specified target value allows for a quantification of the user's condition.

Claims

PATENT CLAIMS:

1. A method for operating at least one application software in a processor circuit of a mobile terminal, wherein a runtime environment of the processor circuit executes a framework software and the respective application software therein as a respective independent module, wherein the runtime environment, which is an operating system or a virtual machine with an operating system contained therein or a container, executes the framework software and in this framework software, in turn, the application software is executed as a binary code module, and user interactions of the respective application software with a user are carried out on a screen of the terminal or an operating device coupled to the terminal via the framework software, wherein the user interactions: • graphical outputs of the application software are displayed to the user via the screen, and / or • User inputs from the user are received by the application software via a touch sensor on the screen, whereby the framework software requests a screen output area from the runtime environment for the currently active application software and then control of the screen output area is transferred from the framework software to the application software for the user interactions.

2. The method according to claim 1, wherein a graphic control interface is provided by the application software and the framework software calls the graphic control interface of the currently active application software for transferring control for outputting graphic content to the screen output area.

3. Method according to one of the preceding claims, wherein the respective application software is designed as an independently executable software, the graphic output of which is exclusively via its REPLACEMENT SHEET (RULE 26) Graphic control interface and through which in particular a separate graphic user interface of the application is output and / or event handling for input events from the touch sensors is carried out.

4. Method according to one of the preceding claims, wherein the framework software operates at least one common service function for each application software, by means of which the respective application software provides input and / or output functionality for interaction with the runtime environment and / or authentication.

5. The method of claim 4, wherein the at least one service function comprises one or more of the following: • user authentication of the user, • a storage service for saving and / or loading media data, • a connection to a Lambda infrastructure, • a backend interface, • cloud access, • reading of at least one sensor coupled to the processor circuit, • Coupling the application software with a vehicle interface for data exchange.

6. Method according to one of the preceding claims, wherein several application softwares carry out their user interactions in parallel or alternately via a single common framework software.

7. The method according to claim 6, wherein the framework software switches between the application software to alternately provide at least one user interaction with each of the application software to the user.

8. Method according to one of the preceding claims, wherein a uniform exchange protocol is used for each application software for an exchange of interaction data of the user interactions.

9. Method according to one of the preceding claims, wherein the respective application software and the framework software are operated in a common address space of the runtime environment as a common process or in separate address spaces as different processes of the runtime environment.

10. Method according to one of the preceding claims, wherein the application software is compiled and / or linked into the framework software as a source code module or is coupled to the framework software as binary code modules at runtime.

11. Method according to one of the preceding claims, wherein the framework software provides a user interface for user interactions.

12. A method for generating user software, comprising the following steps: • Creating one or more application software, each as independently executable software, which provides for user interactions with a user during operation, • individual testing of each application software, • Providing a framework software that has a user interface for user interactions with the user, • Coupling the framework software with the respective application software to the user software, • Operating the user software according to a method according to one of the preceding claims.

13. Method according to one of the preceding claims, wherein the at least one application software comprises a health application for recording and / or evaluating body signals of the user and / or mood information of the user.

14. A computer program with program instructions that, when executed by a processor circuit, cause the processor circuit to perform a method according to one of the preceding method claims.

15. A processor circuit with a computer program according to claim 14, wherein the processor circuit is configured, in particular, as a mobile terminal.

Images