Token and Privacy Device and Method

Abstract

A system, apparatus, and method for monitoring events associated with a person and reporting those events as tokens to other devices or a central server.

Description

Technical Field

[0001] Cross - reference to related applications

[0002]

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 365,457, filed May 27, 2022, which is hereby incorporated by reference in its entirety.

Background Art

[0003]

[0002] The management and distribution of data from one person (including devices and / or services that symbolize that person) to another person, and / or from an individual to an organization, often rely on an explicit or implicit agreement that is beneficial to the recipient of the data. For example, many online services have terms of use that require the data provider to agree to the use of the data for the recipient's commercial purposes.

[0004]

[0003] There are many other situations where the recipient has processes, rules, and its own regulations, and the provider needs to provide data that is not related to, or is mostly irrelevant to, the ongoing interaction.

[0005]

[0004] This is particularly important in the health and medical fields, where the privacy of a person's health management status is of utmost importance and is regulated by law.

Summary of the Invention

[0006]

[0005] Embodiments include systems and methods for enhancing the privacy of a data provider device in a way that allows both the provider and the recipient to engage in the interactions necessary to achieve a mutually agreed - upon result without compromising the provider's privacy.

[0007] Aspects include a system, apparatus, and method for monitoring events associated with a person and reporting those events as tokens to other devices or a central server. The tokens may reference sensor data or data stored in a sensor. Other devices within the system or server may make decisions regarding event response or escalation without needing to access the information stored or referenced by the tokens. Other devices within the system may retrieve data associated with the tokens and use it to, for example, improve event detection accuracy or confirm an event. A device may interpret a combination of acceleration and altitude changes from a sensor as a "fall" event, issue a token associated with the sensor's data, and transmit the event token to a server and nearby terminal devices. The server may initiate a notification to a call center or smart speaker app to start a conversation with that person, while a nearby terminal device may use the token in combination with its identification key or other authentication key and combine the sensor data with data from its own sensors (such as an audio signal from a microphone or microphone array, or an output signal from one or more frequency-modulated continuous wave (FMCW) radar sensors) to request event data from the device and use it to confirm and / or add accuracy to a fall event.

[0008]

[0007] In one embodiment, the system protects the privacy of a person being cared for by at least one caregiver. A plurality of environmental sensors monitor the person being cared for and obtain a dataset of the results detected. The environmental sensors provide a token that includes the detected dataset representing the actions of the person being cared for within the environment. The token is encrypted using an encryption key. Each action is represented by a multi-dimensional feature set that forms part of the healthcare profile of the person being cared for. The care processing system includes a transceiver, a token service module, a non-transitory computer-readable storage medium, and at least one hardware processing unit. The transceiver receives the token from the plurality of environmental sensors. The token service module decrypts the token using the encryption key. The non-transitory computer-readable storage medium stores a stationary dataset that represents the previous stationary actions of the person being cared for within the environment. The at least one hardware processing unit determines a health or care event for the person being cared for by comparing the token with the stationary dataset. When a health or care event occurs, the care processing system is configured to notify at least one caregiver.

[0009]

[0008] In some embodiments, the encryption key is partially selected based on the detected dataset, at least one caregiver, the person being cared for, the type of event detected by the environmental sensors, or unique to the session of the person being cared for.

[0010]

[0009] In an alternative embodiment, the system protects the privacy of the care recipient by at least one concerned person. A plurality of environmental sensors monitor the care recipient, obtain the resulting detected data set, and provide a detected data set representing the behavior of the care recipient in the environment. Each behavior is represented by a multi-dimensional feature set that forms part of the care recipient's medical profile. The care processing system includes a transceiver, a token service module, a non-transitory computer-readable storage medium, and at least one hardware processing unit. The transceiver receives the data set detected from the plurality of environmental sensors. The non-transitory computer-readable storage medium stores a stationary data set. The stationary data set represents the previous stationary actions of the care recipient in the environment. The at least one hardware processing unit determines a health or care event for the care recipient by comparing the token with the stationary data set. When a health or care event occurs, the token service module encrypts the token containing the health or care event using an encryption key, and the care processing system notifies at least one concerned person.

[0011]

[0010] In some embodiments, the encryption key is partially selected based on the detected data set, at least one concerned person, the care recipient, the type of event detected by the environmental sensors, or unique to the care recipient's session.

[0012]

[0011] In yet another embodiment, the system protects the privacy of the care recipient by at least one concerned person. A plurality of environmental sensors monitor the care recipient and obtain the resulting detected data set. The detected data set represents the actions of the care recipient in the environment, and each action is represented by a multi-dimensional feature set that forms part of the care recipient's healthcare profile. Also, the plurality of environmental sensors store the detected data set in a data repository and provide a data token. The data token comprises a pointer to the detected data set detected in the data repository. The data token is encrypted using an encryption key. The care processing system comprises a transceiver, a token service module, a non-transitory computer-readable storage medium, and at least one hardware processing unit. The transceiver is configured to receive the data token from the plurality of environmental sensors. The token service module decrypts the pointer from the data token using the encryption key. The transceiver receives the detected data set specified by the pointer from the data repository. The non-transitory computer-readable storage medium stores a static data set. The static data set represents the previous static actions of the care recipient in the environment. At least one hardware processing unit for determining a health or care event for the care recipient by comparing the detected data set with the static data set. When a health or care event occurs, the care processing system is configured to notify at least one concerned person.

[0013]

[0012] In some embodiments, the data repository stores the detected data set as a blockchain token in a distributed ledger. The distributed ledger may be a permissioned blockchain.

[0014]

[0013] In some embodiments, the encryption key is partially selected based on the detected data set, at least one concerned person, the care recipient, the type of event detected by the environmental sensors, or the care recipient's session.

[0015]

[0014] In yet another embodiment, the system protects the privacy of the care recipient by at least one concerned person. A plurality of environmental sensors monitor the care recipient and provide a detected dataset representing the care recipient's behavior in the environment. Each behavior is represented by a multi-dimensional feature set that forms part of the care recipient's healthcare profile. The plurality of environmental sensors store the detected dataset in a data repository and provide a pointer to the detected dataset in the data repository. The care processing system includes a transceiver, a token service module, a non-transitory computer-readable storage medium, and at least one hardware processing unit. The transceiver receives the detected dataset from the plurality of environmental sensors. The non-transitory computer-readable storage medium stores a stationary dataset. The stationary dataset represents the care recipient's previous stationary behavior in the environment. The at least one hardware processing unit determines a health or care event for the care recipient by comparing the token with the stationary dataset. When a health or care event occurs, the token service module is configured to encrypt the detected dataset or a data token including the health or care event using an encryption key, and the care processing system notifies at least one concerned person.

[0016]

[0015] In some embodiments, the data repository stores the detected dataset as a blockchain token in a distributed ledger. The distributed ledger may be a permissioned blockchain.

[0017]

[0016] In some embodiments, the encryption key is partially selected based on the detected dataset, at least one concerned person, the care recipient, the type of event detected by the environmental sensors, or the care recipient's session.

Brief Description of the Drawings

[0018]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Best Mode for Carrying Out the Invention

[0019]

[0017] Aspects of the present disclosure include a system and method including an apparatus and method for enhancing the privacy of a data provider device in a way that enables a provider to perform the interactions necessary to achieve a result agreed upon by both the provider and the recipient without compromising privacy.

[0020]

[0018] A person may choose to disclose any information that they deem appropriate to another party, but if that other party has devices that sense their activities, environment, and communications, and / or is acting as an agent for another individual or organization, such a choice of information disclosure is often at least partially at risk.

[0021]

[0019] In the case of a device, the degree to which a person has a trust relationship with that device can, at least in part, determine the degree of disclosure that the person can make to the device. For example, in the case of access control and authorization, a person may delegate certain attributes to the device, whereby the device can function on behalf of that person, for example, in the case of a proximity transaction. The device can also be used as a repository for certain data, such as passwords or other confidential data that the person wants to keep secure.

[0022]

[0020] There are many examples of various trust relationships between people and devices, such as smartphones, vehicles, and other smart devices. However, since these devices and many other devices each have a sensing function, they can accumulate a significant amount of data, which can directly or indirectly represent the person's health status.

[0023]

[0021] One approach to resolving the tension among people regarding the privacy and control of such data collection, use, and data flow is to use tokens that represent the data and for the communication, storage, manipulation, management, and / or other use of that data.

[0024]

[0022] For this situation, there are previous approaches that use rule-based systems where declarative rules are expressed and implemented to pursue data control, distribution, and management. However, the flexibility, efficiency, breadth, and scope of such rule-based systems are ultimately limited to the use cases considered by the implementer.

[0025]

[0023] This difficult problem is exacerbated in the use of Internet of Things (IoT) devices, where the existence of a large number of devices with various functions, including unique security features that include a wide range of sensing functions, makes it unrealistic to have an effective rule-based system.

[0026]

[0024] Applying these sensing functions to a person with at least one state of health may enable a large amount of data to be utilized by those related to the devices and / or sensors to which they have access. The use of sensors has increased significantly, whether they are worn, carried, or embedded in the environment. The use of these sensors to provide data particularly related to people's health has also increased significantly.

[0027]

[0025] There are many sensors that can be applied to the environment to determine activities in that environment. These include those that actively transmit signals to the environment, those that capture photons or other electromagnetic frequencies from the environment, those that capture acoustic and other air pressure signals from the environment, and those that are portable and carried to the environment. There are numerous devices that incorporate these sensors, such as accelerometers, gyroscopes, temperature, humidity, motion detectors, cameras, microphones, etc., in various combinations.

[0028]

[0026] Sensors can collect, measure, process, store, and / or transmit data in any combination depending on the sensor's function, the sensor's configuration, and / or the sensor's command and control system or the sensor's connection. In some embodiments, the sensor can measure, store, and / or transmit data based on the sensor's function and configuration. The sensor can determine whether to collect and / or measure or not, as determined by the state of the sensor configured by the system. When the sensor is measuring, it may not be storing or transmitting data. The sensor may be configured to measure, store, and not transmit data, or to transmit data on demand, such as when triggered by the specifications held by the device or when receiving one or more commands from the system.

[0029]

[0027] An important aspect of the systems described herein is the use of tokens as a means for the communication, transfer, and / or use of data collected by one or more sensors, such data forming at least in part a system for monitoring the health status of a person under monitoring (PUM).

[0030]

[0028] The person under monitoring, other individuals and / or organizations with whom the person under monitoring regularly communicates, collectively referred to as stakeholders, the environment in which the person under monitoring normally resides, and devices, services, stakeholders, and other ephemera with which the person under monitoring may communicate can together form a care village.

[0031]

[0029] For communication with other entities within and outside of this care village, tokens can be used as a means of data exchange for any purpose.

[0032]

[0030] Token Characteristics

[0033]

[0031] Tokens can be in any form and simply represent a set of data. However, for almost all instantiations of tokens, there are encryption forms where only the data represented by the token is approved and can be used only by authenticated individuals and / or entities. For example, public key encryption creates tokens that require an encryption key (such as a private key) to access the data represented by the token. Tokens may be signed and / or encrypted with a cipher depending on the purpose of use of these tokens. The data set represented by the token can range from simple integers / characters / algorithms to complex and organized data sets that can form ontologies, hierarchies, taxonomies, and / or other organizational data structures, and such data sets may have at least one set of specifications governing all or some of their representation, communication, storage, disclosure, and / or other characteristics.

[0034] FIG. 1 shows a device (105) that includes a sensor (102) that generates data (105) and a token service module (104) that generates a token (107), which in this example is communicated to a second sensor (108) and stored in a repository (106), during which the device 1 (105) and the sensor 2 (108) monitor a person being monitored within their environment (101). In some embodiments, the token service ((104) may record the generation of the token (107) in the repository, for example, in a distributed ledger.

[0035] A token may represent any dataset by reference or embedding that includes the placement of other tokenized data. Using a token as a representation of data can include the representation of the stored data, and that data can be stored, for example, on or within sensors, devices, and / or internal or external data repositories. This can include cloud-based storage and can be configured for further access, approval, and authentication processes.

[0036] In some embodiments, the token may be recorded in whole or in part in one or more distributed ledgers to provide an immutable record. In this way, the token and / or the data represented by the token are recorded, and for example, when the data represents a care or other event, the occurrence of the event can be established in a way that supports an immutable audit trail without disclosing the data. Access to the data is available only to authorized persons having such access rights, for example, using a public key pair.

[0037] For example, a caregiver providing care for a person being monitored at their place of residence, such as in a care service, may not know specific details regarding the status of the person being monitored that the person wishes to keep private, but can know that an event of attendance has occurred and other data that may be associated with that occurrence.

[0038]

[0036] This function can be configured via tokens that include a set of other tokenized datasets, and access and authentication are such that only specific data can be used by the relevant parties.

[0039]

[0037] This combination of tokenized data is arranged so that multiple parties can participate in multiple datasets while maintaining the privacy of other parties within the nursing home, enabling and supporting multiple care, commercial, insurance, and other facilitated interactions.

[0040]

[0038] Figure 2 shows a device (201) that includes a set of sensors (202) that generate a dataset (203) and a token service module (104) that generates a set of tokens (205). In this example, it is communicated to additional sensors (206, 207), stored in a repository (106), and in the meantime, device 1 (105), sensor 2 (206), and sensor (n) (207) monitor a person (208) under surveillance within their environment (101). In some embodiments, the token service (104) may record the generation of tokens (107) in a repository, such as a distributed ledger. In some embodiments, sensor 2 (206) and sensor (n) (207) may be embedded in additional devices and / or directly incorporated into the environment (101) under surveillance. This can include devices carried and / or worn by the person under surveillance (208).

[0041]

[0039] Token status

[0042]

[0040] In some embodiments, tokens may have specific characteristics that determine their state, such as other attributes and / or characteristics including, for example, time, validity, transactions, value, verification and / or conditions and / or other specifications. These may each be in the form of specifications that can be embedded or referenced. These specifications can include access, authorization, and / or authentication conditions, such that token data can only be used by another party (e.g., including another token) in a situation that conforms to the specifications of the token.

[0043]

[0041] This functionality can be used, for example, in situations where a set of sensors within a specific domain, such as the environment of a person being monitored, exchanges tokens with one or more care signal processing systems and / or one or more digital twins in any arrangement. These interactions can form a network for the benefit of the care and health of the person being monitored, but the specifications of each token may limit access to their token data by other parties than those forming the network.

[0044]

[0042] This network of tokens may also have a state in that such a network may be called by at least one environmental sensing system, care signal processing system, and / or authorized command and control system to assist in the care and health of the person being monitored. For example, in the case of a care event that requires immediate action, such as a fall of the person being monitored, the network can be called during the period of response to that state. After the situation is resolved, such a network, which may include sensors, devices, parties, digital twins, care signal processing, predictive analysis systems, etc., can return to a state managed by a healthcare profile (HCP) having one or more operating patterns.

[0045]

[0043] In some embodiments, a single data record may be represented by a plurality of tokens, and each of those tokens may have different characteristics. For example, the tokens sent to the digital twin may be different from the tokens received by the care signal processing system. For example, the tokens may be constructed to have multiple layers, and for example, the data within each layer may represent different amounts of detail, historical information, temporal data, and the like.

[0046]

[0044] In some embodiments, such a state may be in the form of a session, and such a session may be defined in any arrangement, for example, by time, event, input, result, participant, location, and the like. Such a session can have a set of tokens as part of the session representing data from, for example, sensors, devices, interested parties, and the like. Also, the session may include and / or rely on one or more token minting services, for example, tokens that are unique to the session and can represent a dataset unique to the session, such as a dataset, event, or interaction of interested parties that can only be created within that session. In this way, the occurrence of various devices, events, patterns and / or pattern elements and / or interactions of interested parties can be represented by such tokens. In some embodiments, these tokens may be passed to one or more digital twins and may act to form part of a session, and the prediction and / or other care-related capabilities of the digital twin may be incorporated into such a session for the benefit of the person being monitored and their current care and health status. This can include one or more machine learning / AI prediction functions of the digital twin.

[0047]

[0045] In some embodiments, the set of tokens representing the session data may be accessed based on the characteristics of the session, including the interested party calling the session, the care conditions of the session, session access, and any specifications determining session authorization and authentication.

[0048]

[0046] In some embodiments, the care hub may be employed to generate a session token representing one or more states of a pattern of operation within the environment. This may include reference aggregation and / or embedding of multiple token types into a multi-segment token, for example, as a representation of the state of one or more patterns.

[0049]

[0047] FIG. 3 shows a person being monitored in a monitored environment (101) and is partially monitored by device 1 (201). This device includes one or more sensors (202), device logic (303), token service (104), and a secure elastic repository (304). In this example, the token service may create one or more tokens of different token types (301) depending on the function and / or configuration of the token service (104). A second sensor 2 (206) is shown here receiving a configuration token (305) generated by the device 11 (201) token service (104).

[0050]

[0048] In some embodiments, when a session is initiated, such a session may include one or more patterns and / or pattern elements. For example, a pattern representing a transition from one operation pattern to another may be represented by one or more tokens including predictive and / or transitional operations represented by such patterns and / or pr pattern elements. For example, events or changes in the health status of a person being monitored may be of concern to interested parties, and these tokens may be passed to appropriately authorized interested parties. For example, the interested parties may be medical professionals, insurance companies, and / or relatives.

[0051]

[0049] In some embodiments, in combination with one or more smart contracts or other system representations, the verification of a series of occurrences may be incorporated into a smart contract, for example, represented by a token. Thus, for example, a smart contract can access a token dataset and execute one or more programmatic processes to verify the events and / or sequence of occurrences represented by the token, for example, to prove that such events exist, i.e., occur at a time and place and involve certain parties and include certain events and occurrences, and / or meet one or more specifications of such an event sequence.

[0052]

[0050] Figure 12 shows a person being monitored in a monitored environment (101), and the first sensor and the first dataset (1201) respond to event detection. In this example, the event and the data representing such an event are securely communicated to a first token service (1204) that generates one or more tokens, for example, data tokens, configuration tokens, event tokens, and / or pattern tokens (1209). One of these tokens (1209) is a configuration token communicated to a second sensor set (1202) and configures the sensor set (1202) to generate data that can be evaluated for verification of the initially detected event. In this example, the care system (1212) evaluates the data of the second sensor set (1202) and instructs the token service (1205) to create one or more additional tokens, in this case configuration tokens, and communicates them to a third sensor set for capture of additional datasets from the person being monitored and their environment (101). In this example, all tokens and their creation data are stored in a repository (1207) integrated with a distributed ledger (1208).

[0053]

[0051] In many situations related to the health of a person being monitored, specific compliance data may be required to meet various conditions. Such conditions can be expressed, for example, by one or more stakeholders involved with the person being monitored. This includes ensuring that the recipient of the token, such as an insurance company, an operator of a care facility, a friend or family member, a healthcare worker, etc., is guaranteed that the events, activities, or other data represented by the token occurred in accordance with the specifications. This compliance information can be represented as a token. In some embodiments, this may include the use of smart contracts and distributed ledgers. In some embodiments, window access to data represented by tokens may be used. For example, in the event of an emergency, the data sets held by one or more tokens may become available while the emergency is occurring, but when the situation is resolved, these tokens may restrict access to specific data according to general specifications. For example, when the pattern transitions from a stable situation to an unstable situation, i.e., in an emergency, the system may make tokens available so that parties involved in such an emergency, such as emergency responders, can access the data. In some embodiments, such an emergency may be for the session in which the tokens were created, and different parties may access all or part of the data sets accessible by the tokens according to their IDs. This includes the device being able to access the data. However, the data may only be available during the period of the emergency. This may be made possible, for example, by using at least one application, cloud service, digital twin, etc. Also, there may be permanent records for, e.g., audit trails, digital twins, distributed ledgers, etc. In some embodiments, the tokens may be accessible through the provision of other enabling means that support access to a specific key, authentication indicator, or date for a set of specific situations. This can include, for example, time, location, proximity of parties and / or specific devices or facilities, the ID of one or more parties, one or more data sensor sets, one or more patterns, etc. These specifications may be represented by additional tokens that require, for example, both the token containing the data of the person being monitored by the application, device, and / or system, and an authorized access token placed within the specific period during which access is provided.

[0054]

[0052] Tokens for Sensors, Devices, and / or Systems

[0055]

[0053] In some embodiments, each of the sensors, devices, systems, and parties has a unique ID. This ID can be self - assigned and / or provided by the system service, but is unique within the network in which the sensors, devices, and / or systems operate.

[0056]

[0054] In some embodiments, a token can be a binary and / or text string that uniquely references a record, for example, stored separately within a database system to restrict access to the record and described as a lightweight token. In other embodiments, a token can be a binary and / or text string that contains data, typically in a digitally signed and encrypted format. For example, one common implementation of such a type of token is a JSON Web Token (JWT) that contains a signed and encrypted JSON - formatted object. A JWT token consists of three parts: a header, a payload, and a signature. The header contains information about the algorithm used to sign the token, and the payload contains related data, which in some embodiments typically includes user authentication and access information. The signature is used to verify that the token has not been altered during transmission.

[0057]

[0055] In some embodiments, a token can be a combination of two approaches that reference and contain data. For example, a JWT token can be created using a payload that includes a portion of the data of the person being monitored and one or more references to additional data of the person being monitored stored separately. For example, sensor, device, and / or system data can form part of the payload, similar to the configuration data of one or more sensors, devices, and / or systems.

[0058]

[0056] In some embodiments, this may include configuring such communication endpoints to access a plurality of token segments. Such a configuration can use one or more proprietary algorithms and / or encryption techniques to enable only authorized endpoints to access such data.

[0059]

[0057] FIG. 20 shows a set of devices (2001) including at least in part a sensor (2002), device logic (2003), a token service (104), and a secure elastic repository (2005), which are engaged in monitoring a person (208) under surveillance in an environment (101), resulting in the generation of a data set represented by different types of tokens (301) that are communicated to a care hub (1803) including at least in part the token service (104), and a protected processing environment (1801) and care hub management (1802) are configured to generate a set of session tokens (2007) representing the state of the patterns operating for such monitoring. In this example, such session tokens (2007) are transmitted to the care processing system. In this example, each of the devices (2001), token types (2006), care hubs (1803), and session tokens (2007) are stored by reference or embedded in a repository (105).

[0060]

[0058] Multi-segment token

[0061]

[0059] In some embodiments, a token may include a set of segments, each of which can have a different access method. Such a multi-segment token can include a binary string and / or a text string that uniquely references a record by reference or embedding. The configuration of the token and one or more endpoints can be such that only a particular endpoint can access a designated segment of the multi-segment token. For example, in a token having five segments, different endpoints can be configured to access only segment 3 or 5, for example.

[0062]

[0060] FIG. 10 shows a multi-segment token (1008) including one or more token IDs and a plurality of data sets, each data set being available to a particular stakeholder (1001...1007).

[0063]

[0061] Decentralized tokens are created and managed on a decentralized network such as a blockchain or other types of digital ledgers. Unlike conventional tokens created and managed by a central device or central authority, decentralized tokens are created and managed by a decentralized network of devices and / or users according to a set of rules regarding consensus and security. One of the main advantages of decentralized tokens is that they are trustless, meaning that there is no need for a central authority to verify or validate their creation and access. Instead, the token and the associated transactions are verified and validated by the decentralized network itself using complex algorithms and consensus mechanisms. Decentralized tokens are often used as a means of exchange or as a means of storing value such as currency, securities, property, or even virtual goods in online games. However, they are also useful in cases where information needs to be stored, represented, and / or exchanged in a secure and verifiable manner. For example, in the representation and distribution of care and health data of a person under surveillance, the privacy of the person under surveillance and the security of the data regarding the person under surveillance are adequately provided by such an approach.

[0064]

[0062] In some embodiments, a common way to create a decentralized token is to use various public blockchain platforms such as Bitcoin, Ethereum, or Binance Smart Chain, or private or permissioned blockchains. The data represented by the token can be stored in the decentralized ledger itself (on-chain storage) or an external storage system such as a database, and the ledger holds references to such externally stored data (off-chain). A combination of on-chain and off-chain data storage may also be used.

[0065]

[0063] In some embodiments, the token can also be issued and managed by a single entity operating as a centralized service, such as a sensor, device, system, care hub, or other computing subsystem. These can hold data in any arrangement in local storage and / or database, and / or external storage and / or repository system.

[0066]

[0064] FIG. 8 shows a person being monitored in a monitoring environment (101), with one or more devices (805) including sensors (802) that generate data (803) at least partially monitoring the person being monitored and / or the environment (101). In this example, the data (803) is securely communicated to a token service (104), which generates a token set (804) that is communicated to a care hub (801). The care hub can then, for example, transmit the tokens to a repository (105), a care processing system (504), and / or a digital twin (701) in any arrangement.

[0067]

[0065] In some embodiments, a device, such as a sensor device and / or system, e.g., a care hub, may directly issue a token that holds or refers to data generated and / or stored by the sensor, device, and / or system through reference or embedding. The sensor, device, and / or system may use an external token issuing system to create the token.

[0068]

[0066] The creation and issuance of such tokens may be based on one or more thresholds, periods, events, action responses, and / or other specifications. This can include one or more authorizations for the issuance of one or more tokens and may include the specification of one or more endpoints that can access the data payload of the token. For example, in the case where the token is a reference, if a particular event has occurred, such as a caregiver having cared for a person under monitoring at a particular location for a certain period of time, the data payload of the token is the token itself, and thus the endpoint will have an appropriate method for extracting the payload. This can include forming a multi-dimensional feature set contributed by the sensor, device, and / or system and / or one or more thresholds based thereon.

[0069]

[0067] In some embodiments, tokens containing data in encrypted form can be resolved by any device that has access to the decryption key. Public key mechanisms such as Rivest-Shamir-Adleman (RSA) or Elliptic Curve Cryptography (ECC) can be used to securely exchange the tokens. For tokens issued by a particular sensor, device, and / or system, including an external storage subsystem that includes a reference to externally stored data, e.g., a care hub, the external storage subsystem can be based on an authentication / authorization scheme and / or provide an access control mechanism that can be combined with other control parameters such as time and location.

[0070]

[0068] Decentralized tokens such as those based on blockchain may be combined with smart contracts running in a protected computing environment of the blockchain to provide access control to token reference data.

[0071]

[0069] In some embodiments, one or more bearer tokens, sensors, devices, and / or systems can be biometrically coupled to a person or other party being monitored, and the bearer tokens are created and managed by such sensors, devices, and / or systems. Such bearer tokens are representative of the person being monitored and can support one or more operations and / or interactions in certain situations and cases. In some embodiments, such bearer tokens can form part of the ID of the person being monitored or other party.

[0072]

[0070] In some embodiments, the emergence of practical quantum computers may break many of the currently used encryption methods, including RSA and ECC. Some embodiments may use quantum-resistant or quantum-computer-resistant cryptography, such as lattice-based cryptography, as part of the implementation of a centralized or decentralized token issuance and settlement mechanism.

[0073]

[0071] Figure 4 shows a person being monitored in an environment (101), including at least partially a sensor set 1 (407), and the sensor set 1 (407) can generate sensing data (403) and configuration data (404), both of which are provided to a token service (104). In this example, the token service creates a set of tokens (107) that are communicated to a further token service (402), and the token service (402) can extract the configuration data represented, for example, by the tokens (107) and generate configuration tokens (401) that are communicated to a second sensor set (405) that monitors the person being monitored and the environment (101). In this example, the token service (402) can store the tokens (107) in a repository (106).

[0074]

[0072] One aspect of the system is the use of tokens that represent characteristics such as sensors, devices, and / or the functions, configurations, IDs, etc. of the system. This supports the privacy of the functions of these devices, and only authorized IDs can access these characteristics represented by the tokens. The specifications of these sensor, device, and / or system interfaces (including, for example, API calls) may be included such that access to the configurations of the sensors, devices, and / or systems, and / or the data sets generated thereby, is performed by an authenticated and authorized entity. In some embodiments, this may involve an upfront exchange of tokens between two or more sensors, devices, and / or systems to establish relationships that are authenticated and authorized by all parties involved. Such relationships may be established directly and / or with third-party services and may include, for example, the use of public-key encryption. In some embodiments, such a configuration may be stored by the device through embedding into device storage or through the use of a connected storage function. In this example, the selection of the configuration of the device and / or sensor can be performed by an authorized entity using tokens that represent those configurations. This data set represented by the token may be communicated, for example, to a care signal processing system, and then the care signal processing system can call one or more processes. For example, the token may represent the state of the device, including environmental and monitoring of the person being monitored.

[0075]

[0073] In some embodiments, even if the device / sensor has functions other than those specified in the configuration, such as the ability to record video, audio, etc., the pre-set device configuration may be the only way to change the operation of the device and / or sensor so as to limit the use of such characteristics to effectively and / or enforce the privacy of the person being monitored, the environment, and / or other relevant parties.

[0076]

[0074] These unique characteristics of the device and / or sensor can be made available in any combination to one or more systems and / or their elements, such as, for example, a care signal processing system, but the use of tokens as a representation of data that can be created, stored, managed, and / or transmitted provides the ability to effectively manage the extent to which this data is made available to authorized recipients. Examples include those operating in a care monitoring system, such as a care signal processing system, one or more operation patterns, HCPs and / or devices, digital twins, etc.

[0077]

[0075] FIG. 16 shows a person and environment (101) under surveillance, with a set of sensors (1601, 1602, 1603) monitoring the environment and the person under surveillance. In this example, a token service (104) generates and issues a token for the sensor set (1601). The sensor sets (1602, 1603) include, in this example, a token service module and generate, for example, configuration tokens (1604) which are communicated outside of these sensor set token services (104). In this example, the configuration tokens (1604) are potentially communicated on demand and / or dynamically to one or more digital twins (701), and such configurations can be deployed within one or more digital twins using, for example, a machine learning / AI module (901) by a care processing system (504) for evaluation. Such evaluation can be used to determine all or part of the variations in the behavior or patterns of the person under surveillance. This can result in an output that is communicated to a response system (902). In some embodiments, the response system can provide a warning or other message to one or more interested parties (1606).

[0078]

[0076] In some embodiments, each sensor, device, and / or system may have a privacy profile represented by one or more tokens, such as an ACL, a set of specifications, authorization relationships, etc. This profile can be created by, for example, the owner of the device including the person being monitored, the operator of a care facility, a person related to an accredited care village such as a healthcare worker, an emergency service including an operator, etc.

[0079]

[0077] In some embodiments, such settings may be overwritten by an authorized entity if the situation is of a nature that requires data designated as non - public to be made available for specific times and / or events, such as emergencies where the care and health of the person being monitored are at significant risk.

[0080]

[0078] Tokens and Privacy

[0081]

[0079] The determination of which data is considered non - public can have important consequences for one or more various stakeholders within a care village. There may be no common agreed - upon perspective among stakeholders and systems regarding the set of data that a stakeholder might consider non - public. Each stakeholder may want to ensure that certain data is kept non - public and / or is made unavailable to other stakeholders and / or other individuals, entities, or systems for a specified period.

[0082]

[0080] This is particularly important when dealing with the personal health status, medical records, financial information of the person being monitored, and / or other matters considered or mandated as personal data by one or more legal statutes such as HIPAA, PII.

[0083]

[0081] The problem is, in the context of providing monitoring of the health and care of a person under monitoring, a method of optimizing the potential care and health outcomes of a person receiving care, ensuring that only the relevant parties providing monitoring and / or care and health can access the appropriate data. For example, notification of a severe allergy may be essential for an emergency medical technician. A further aspect is to ensure that the dataset used for care and health provision and support is retained only by the relevant parties that require such data during the period of care and health provision and / or support for the person under monitoring. However, it may be necessary to create a record in the form of an audit trail providing evidence of such provision and support by the relevant parties involved in the time and location of such an event. To achieve this objective, tokens may be employed to provide such immutable records in the form of records written, for example, to one or more distributed ledgers, without revealing all the details of such provision and support, except to authorized and authenticated parties such as medical personnel like doctors.

[0084]

[0082] Figure 11 shows a set of sensors (1101 - 1107) involved in monitoring a person under monitoring in a monitoring environment (101), and the datasets from these sensor sets form part of a multi-segment token (1111), and only specific parties (1108, 1109, 1110) receive specific datasets forming specific sensors. For example, party 1 (1108) can only access datasets 1, 2, and 3.

[0085]

[0083] The use of tokens provides a means to facilitate such data privacy while ensuring that the data available is only that which is essential for the care and health state management required at that time.

[0086]

[0084] Figure 5 shows a person being monitored in an environment (101) that is partially monitored by a device (501), equipped with sensors (502) that generate data (503), which is then communicated to a token service (104), which then generates a token set (107) and then communicates it to a care processing system (504).

[0087]

[0085] In some embodiments, the data can be transferred to one or more digital twins to support a prediction system that can include one or more machine learning processing modules. For example, a digital twin can be instantiated to predict one or more future care and health states of the person being monitored, at least in part based on the person's HCP and operation patterns. In this example, the digital twin may represent a set of future care and health states of the person being monitored, and such predictions are based at least in part on a dataset provided by one or more sensors, devices, and / or systems involved in the monitoring of the person being monitored. In some embodiments, such a dataset can result from one or more persons being monitored within an HCP having a specific operation pattern where a specific ID, location, or other PII is not revealed to the digital twin. This can include a dataset that can be distributed to interested parties through tokens.

[0088]

[0086] Figure 17 shows a person being monitored in an environment (101) under surveillance that generates one or more datasets including configuration data, where one or more sensor sets (1701, 1702, 1703) are securely communicated to a token service (104). In this example, the token service (104) generates a set of tokens (1704) representing the data received from the sensors (1701, 1702, 1703) and communicates it to a care processing system (504). The care processing (504) can then call a digital twin (701) and / or a machine learning / AI module (901) to support one or more commands to a response system (902).

[0089]

[0087] Since the digital twin can represent the care and health status of the person being monitored and their environment with sufficient fidelity, it can be used in predictive analytics, including the use of machine learning, for the benefit of the care and health of the person being monitored. In many situations, the digital twin can be one of a set of digital twins that represent a set of people being monitored with a common set of care and health characteristics, such as the same or similar HCPs and their operating patterns and pattern elements. The degree of disclosure of the dataset related to the person being monitored to the digital twin should be sufficient for the digital twin and related analysis and / or predictive processing to perform effective prediction, trends, identification of the underlying care framework, and / or other care and health benefit processing. This can be achieved in many ways by adopting different embodiments. For example, the token can include a set of specifications that can be interpreted by an appropriately authorized digital twin that can potentially access data considered private by the person being monitored on a time and / or function-limited basis for a specific purpose. This type of disclosure may be pre-agreed by the person being monitored. The data received by the digital twin can be erased after appropriate analysis and / or processing has been performed. In some embodiments, the digital twin can operate as a proxy for the person being monitored such that all data is available to the digital twin and the digital twin functions as a privacy guardian for the person being monitored, formulating and implementing the privacy choices of the person being monitored. In further embodiments, there may be tokens that are digital twin-specific and include additional specifications that determine the use, propagation, and / or configuration of the tokens and the digital twins that act on them.

[0090]

[0088] An important aspect is that the digital twin maintains a relationship of trust with the person being monitored, even if it consists of one or more components, so that the data considered private by the person being monitored remains as it is, and the digital twin can function to support the monitoring of the care and health of the person being monitored for the benefit of that person.

[0091]

[0089] Figure 7 shows a person under surveillance in the environment (101). This person under surveillance is at least partially monitored by a device (705) comprising a sensor (702) that generates data (703) representing at least in part the person under surveillance and the environment (101) under surveillance. In this example, the data (703) is securely communicated to a token service (104) that generates a token set (704). The token service may communicate all or part of the data represented by the token (704) and / or data including such tokens and / or the process of generating such tokens to an appropriate repository (105). In this example, the token is communicated to a care processing system (504), which can then communicate the token and / or the data represented by the token to one or more digital twins. In some embodiments, the token (704) may be communicated directly to the digital twin (701).

[0092]

[0090] In some embodiments, a distributed ledger system such as Ethereum can be introduced to support this system functionality. For example, this can include a virtual computing environment that maintains state, executes any machine code, combines ledger data and external inputs to provide an output based on an organized logic or computation called a smart contract, and / or changes the state of the distributed ledger, all within a protected network distributed computing environment. This can be combined with tokens to enable functions such as selectively converting tokens into data sets, representing the interpretation of tokens (from the token to its meaning within the context of the caller), and the creation of new tokens from the combination of input tokens and data within the distributed ledger. The combination of these functions can be used in smart contracts that provide information and services without executing transactions and exposing private or sensitive information or functions to unauthorized parties, and without restricting the availability of functions necessary for care and health monitoring and response within a highly secure environment.

[0093]

[0091] In some embodiments, one or more smart contracts can be used to verify a dataset related to a person under surveillance, such as that created by one or more sensors, events, tokens, and / or aggregations, before it is stored in a distributed ledger. This may include a dataset that can be used for training a machine learning model and / or digital twin-based modeling and / or simulation to improve the efficiency, transparency, accuracy, and / or quality of one or more machine learning processes and / or predictions, inferences, and / or other results of one or more digital twins.

[0094]

[0092] In some embodiments, there may be one or more protected processing environments (PPEs) that can perform the evaluation and / or processing of one or more datasets represented by one or more tokens in a secure manner. In this sense, the protected processing environment becomes an extension of the token during the processing of such token data, and the conditions of the token expressed as a specification are respected and / or enforced by the PPE. For example, the PPE can be dynamically instantiated by an environmental sensing system, a care signal processing system, and / or other authorized care village system elements, such as those that manage at least one care village, including sensors, devices, and / or their systems. These protected processing environments can create additional tokens representing the data on which the protected processing environment operates and store such data, for example, in a secure repository of the protected processing environment and / or a repository such as a distributed ledger.

[0095]

[0093] Figure 13 shows a person being monitored in a monitoring environment (101), and at least in part, a set of devices (1301) including sensors (1306) and data (1307) communicate such data to a token service (104) to generate a token (1302). In this example, the token (1302) is communicated to a system (1303) including at least in part one or more PPE (protected processing environments) (1304), and in combination with a token service (1310) and / or device logic (1309), one or more tokens and the data (1308) they represent can be processed in a secure and protected manner. In this example, the operations and data of the tokens, processing, device logic, and / or token service can be stored in a repository (1305). In some embodiments, such a system (1303) may be embedded in one or more devices (1301) and / or may be invoked by such devices, for example, through a cloud service.

[0096]

[0094] The digital twin can at least partially provide a virtual environment for the caregivers of the nursing home to interact, for example, for training, practice, anonymized interactions, etc. In some embodiments, the system can use predictive caching to evaluate that one or more caregivers can be alerted when the likelihood of an event, such as a fall, coughing fit, shortness of breath, etc., exceeds one or more thresholds, as represented, for example, by a multi-dimensional feature set. For example, a warning can be received via a device, or a dataset related to the predicted and / or anticipated care and health status can be pre-loaded. This data can be in the form of tokens and is available, for example, only when the caregiver and the device are in proximity to the person being monitored. Such a person being monitored may also be equipped with devices such as PERS and / or other portable or wearable devices, or when the caregiver and the person being monitored are engaged in care and health-related activities locally or remotely. If the data has been pre-loaded, the data can be made available, but if that state does not occur, the dataset remains unavailable.

[0097]

[0095] In some embodiments, blind signatures can be used as part of part or all of the token. The use of blinding can support various privacy schemes, including those of sensors, devices, and / or systems. For example, data collected by a sensor can be provided to any number of other authenticated and / or authorized sensors, services, systems, and / or devices, either encrypted or unencrypted. However, to protect the privacy of this source and / or the person being monitored, the original sensor and / or the ID of the person being monitored may be blinded.

[0098]

[0096] Privacy can be configured on a per-sensor, per-device, and / or per-system basis so that each sensor, device, and / or system can store data collected by such sensors, devices, and / or systems and transfer such data to one or more repositories in a secure manner. The repository may be, for example, a part incorporated within such sensors, devices, and / or systems including the sensor, device, and / or system, and / or a repository securely connected to such sensor, device, and / or system through one or more communication methods. This can include the use of tokens as all or part of the communication method, where each token can be configured to represent one or more data sets and / or the sensor, device, and / or system ID of the originator, and the transfer of tokens is only possible between sensors, devices, and / or systems authenticated by the sensor, device, and / or system and / or the sensor, device, and / or system of the originator. The security for such transfers can be implemented using cryptographic methods including PKI and may include the use of blind signatures.

[0099]

[0097] In some embodiments, the sensor may generate a token based on the data set created by the sensor and immediately transfer it to other sensors, devices, and / or systems that are properly authorized and authenticated so that the data set created by the originating sensor is not retained. In this way, such a sensor does not retain a record of the data set. In some embodiments, the sensor may not retain any of the generated data sets, but may retain and / or transmit a record of the transfer of that data set to another sensor, device, and / or system. For example, this may be in the form of a token including the ID of the originating sensor, device, and / or system, temporal data such as the time and duration of the transfer, the IDs of the sender and receiver, and / or an acknowledgment of receipt of such transfer by the receiving side.

[0100]

[0098] Figure 6 shows a person under surveillance in a monitored environment (101), where a plurality of devices (501, 507) each include a plurality of sensor sets (502, 505) and generate a plurality of data sets (503, 506). In this example, these data sets (503, 506) are securely communicated to a token service (104) to generate a token set (601, 602) representing those data sets. These are then transmitted to a care processing system (504) which, in this example, may communicate with one or more sensor sets, such as sensor (505), and have one or more tokens and / or data represented by such tokens.

[0101]

[0099] In some embodiments, the sensor may generate one or more data sets, which may then be processed by such a sensor and / or a secure proxy processor for the sensor. This can incorporate such data sets into a multi-dimensional feature set, and processing such as care signal processing can be employed to identify and / or recognize one or more events and / or event sequences, all or part of which include behavioral patterns and / or pattern elements within the HCP for one or more monitored individuals. These data sets representing one or more events and / or event sequences can then be held, in whole or in part, by the sensor, device, and / or system, and / or transmitted and / or transferred to one or more other sensors, devices, and / or systems. In some situations, for example in the case of geofencing, the held data may become available in other systems. For example, in the case of a care signal processing system, the data is provided to the care signal processing system on a time-specified, demand, or request basis if so requested by such a system and / or the configuration of the sensor. In some embodiments, the retention of these data sets can be configured by one or more sensors, devices, and / or systems such that the data can be stored for a specified period and / or then transferred to one or more other sensors, devices, and / or systems and / or erased or discarded. The record of sensor processing events may be stored in one or more repositories, including a distributed ledger, without the underlying data being stored or made available in any other sensor, device, and / or system.

[0102]

[0100] In some embodiments, a sensor, device, and / or system may be configured to hold and / or store a dataset based on one or more location-based references, such as location geofencing. In this way, data can only be held when one or more sensors, devices, and / or systems are active at a particular location. They can be further configured to limit the period during which such data is held. For example, only during working hours, or conversely, only when the person being monitored is asleep.

[0103]

[0101] The representation of the privacy of a dataset regarding a person being monitored and their environment is at least partially context-dependent, and in that context, it at least partially determines access to and acceptance of information related to the person being monitored, their environment, and the events therein, and can be implemented and enforced through the expansion of one or more tokens representing these datasets. This is typically dynamic and real-time, and often involves pattern and / or event-driven data sharing.

[0104]

[0102] In some embodiments, the tokens may be pre-configured or configurable. For example, there may be standard tokens representing recurring events, occurrences, specifications, etc., which can be shared among multiple sensors, devices, systems, and / or stakeholders, such that each of them can provide data to such tokens and / or provide a configured dataset through reference or embedding.

[0105]

[0103] One aspect is a sequence of token creation, use, and / or redemption, where for example a particular set of tokens in a particular order forms part of a pattern and / or pattern element and / or can represent an event and / or event sequence. For example, the order of token exchange, communication, and / or transfer between a set of sensors, devices, and / or services may be independent of the event order and / or event sequence represented by one or more tokens.

[0106]

[0104] The combination of proximities, including the presence of a person in the environment of the person being monitored, may wholly or partly determine the degree of data exchange between the environment, the parties involved, the sensor devices, and / or the system. In an example where the person being monitored is present, tokens, sensors, devices, and / or systems may be configured to restrict the distribution of some data sets, for example via an application and / or configuration, such that only certain parties, devices, and / or systems receive a particular data set, for example via a device acting as a proxy. This representation of data privacy by the person being monitored may be subject to the HCPs they operate under, and data that is not available to the parties, sensors, devices, and / or systems may be transferred to the digital twin.

[0107]

[0105] In some embodiments, the temporary relationship with third-party devices such as Alexa, smart TVs, smart speakers, etc. can be established through the use of temporary tokens and resolved by such devices through an intermediary such as a cloud service, router, care hub, network device, or other translation service. For example, to support a person being monitored when an event is temporarily occurring on the device, such as a transition from one pattern to another, it is configured to provide data to other sensors, devices, systems, and / or services. This is the case when the person being monitored enters an environment where they do not normally reside and / or when a person such as a caregiver enters that environment. In many cases, such third-party devices can be configured to provide data that supports a first set of sensor data, such as data generated by PERS or other wearable or portable devices. This may include a communication function with other parties such as the person being monitored and / or a caregiver. For example, such data may provide data to confirm the situation, verify the date from the sensor, and / or mitigate events or actions. Such data may optionally provide context information that is part of the environmental sensor array based on timing criteria. For example, such a device may be configured to listen for coughs, falls, or other occurrences of care and health.

[0108]

[0106] Issuance of Tokens

[0109]

[0107] In a nursing village, there may be multiple authorities that issue tokens. For example, the issuing organization may have a domain of an elderly care facility or a number of operators of elderly care facilities. In this example, such an operator may issue tokens that are specific to the operation of the organization and / or tokens that are interoperable with the token systems of other organizations. The determination of the scope of token operations that a facility can support can be instantiated using the smart contract, public, private, and shared distributed ledger decisions of the issued tokens. In some embodiments, this may include the use of the ability to exchange tokens issued by one organization with tokens issued by another organization and / or tokens recognized on an overall system basis.

[0110]

[0108] In some embodiments, one or more issuing services operating as an issuer may be instantiated to provide one or more token generators with the appropriate authority to create one or more tokens. In some embodiments, such a token generator may be a hardware device that includes an FPGA or other programmable hardware element that can generate tokens based on one or more algorithms such as hashes. In some situations where the token represents a dataset that is considered private and / or secure, the token may communicate with the issuing service to apply one or more encryption techniques to such a token in order to ensure the privacy and security of the data represented by the token. In some embodiments, this may include a token that includes sufficient token identification such that the token can be directed to appropriate receiving sensors, devices, and / or services while maintaining the privacy and security of the dataset represented by the token.

[0111]

[0109] In some embodiments, the token can be created by one sensor, device, and / or system that can be interpreted by another sensor, device, and / or system, providing a means for data exchange between two sensors, devices, and / or systems. Such token creation sensors, devices, and / or systems, and token interpretation sensors, devices, and / or systems may be arranged in the same physical or logical arrangement, and these arrangements can provide additional information sets based on the relationships between the devices, tokens, and / or issuing authorities. For example, timestamps, network locations, MAC addresses, and other metadata can be provided as part or in addition to part or all of the token exchanged between sensors, devices, and / or systems.

[0112]

[0110] An embodiment may use different mechanisms to represent data as tokens. These mechanisms include, for example, that the token is an encrypted version of the data, that the token is an address (encrypted or otherwise) of a data storage (local, centralized, or distributed) system or a storage location of data in a distributed ledger, that the token is an index to data in a data storage, and that the token is an identifier of data such as a distributed ledger or a database management system (local, centralized, distributed). Depending on the mechanism used to represent data as tokens, such as those instantiated in a token service module, there may be various token issuance functions. For example, different types and complexities of tokens may be issued by one or more sensors, devices, and / or systems. In some embodiments, along with the events and / or generated data held by the sensor, the sensor may issue a token representing the event or occurrence. For example, a camera or other detector using edge detection may detect a change in the vertical alignment of a person being monitored, which may indicate a fall. In this example, the sensor may issue a token representing a change in the state of the person being monitored to a service that monitors the state, such as a care processing system. With this token, such a system can evaluate other sensor data, such as what the person being monitored is carrying or wearing, to confirm whether this is a fall or the person being monitored has suddenly sat down.

[0113]

[0111] When the token is an encrypted version of the data, an encryption algorithm such as AES may be applied to the data and issued by a sensor, device, and / or system. The device may also issue a token when the token mechanism is an address or index to data in a data storage. In such cases, the data storage may be local or external and / or distributed. Similarly, when the token is an identifier within a storage or database management system, such a system may be present within the device or external to the device.

[0114]

[0112] In some embodiments, the token can be an address, identifier, or other reference to data stored in a storage system external to the device, and such a storage system may be a distributed file storage system such as the Interplanetary File System (IPFS), where multiple devices connected via a computer network store data in a cooperative and distributed manner using a protocol.

[0115]

[0113] When the token represents data stored in a distributed ledger, the device may include a local node of the distributed ledger and / or may be connected to a node of the distributed ledger. By initiating a transaction within a distributed ledger that executes a smart contract including token issuance, the device may use a distributed ledger node to request token issuance. This transaction can be verified by a consensus mechanism of the distributed ledger such that the smart contract is executed and, if successful, the token is returned to the device. This token may be an address of a data record within the distributed ledger, or other representation of data within the distributed ledger, data ownership, and other attributes. In some embodiments, the verification of the requested transaction, execution of the smart contract, and / or storage of data can have a unique cost that must be paid by the requester. This cost may be converted into a financial cost or may be abstract, and may only exist as a mechanism to control the use and access of resources within the distributed ledger.

[0116]

[0114] Tokens, particularly those based on a distributed ledger mechanism, can have value that can be exchanged, aggregated, combined, and / or used in transactions related to financial or care services.

[0117]

[0115] In some embodiments, there can be types of token issuance, such as an open token system where token issuance is unrestricted, or a closed token system where token issuance is restricted, but in some embodiments this may be extensible. The choice of deployment strategy may be affected by token distribution, issuance cost, etc.

[0118]

[0116] In some embodiments, a particular device or class thereof may have the ability to issue tokens, while other devices may only be able to receive and / or redeem tokens. This can include situations where a device, such as a sensor deployed at a particular location to monitor a particular person under surveillance, can only issue tokens that include the device's ID (which may incorporate time, location, and other identifying characteristics). In some embodiments, this may be the only way such a sensor can propagate data generated by such a sensor. In this case, such a sensor may be able to receive and interpret a particular type of token, such as a configuration token that includes data specific to that sensor or class thereof. Such tokens can have encrypted and / or referenced ID information so that the sensor will accept such tokens only if the ID information is recognized as a genuine, authorized, and verified source of such configuration information. This approach can be instantiated using standard authentication, authorization, and access control techniques (AAA).

[0119]

[0117] In another example, in a generally secure manner such that processing overhead is removed from the sensor, the sensor may delegate token issuance to a service accessible to the sensor. In many situations, this may involve the sensor being hardwired and / or using a closed and / or secure communication system to such a service such that the service can function as a proxy for one or more sensors. For example, such hardwiring and / or closed communication system may be a closed system with no external access to the sensor other than via the service. Such a service may receive, interpret, and as a result configure sensors controlled by the service upon receipt of a configuration token. For example, a care hub may function as such a service, and each sensor operates in an environment connected using a hardwiring and / or closed secure communication system, such as using MAC addressing or other appropriate hardening techniques, e.g., hardware addressing.

[0120]

[0118] In some embodiments, any sensor, device, system, and / or party may issue tokens, either directly or via a proxy, e.g., a token issuance system. These tokens may form a localized arrangement where tokens can only be issued and redeemed by a closed set of authorized and authenticated IDs. For example, this may be a family group, a person under surveillance and their caregiver, a person under surveillance and medical staff, etc. Such localization may be performed based on physical and / or logical decisions. For example, a person under surveillance may localize a group to themselves and their digital twin.

[0121]

[0119] Configuration of a Distributed Ledger

[0122]

[0120] In some embodiments, the distributed ledger may include at least one protected processing environment and / or may be connectable. Such arrangements can support both fungible and non-fungible tokens. Such distributed ledgers may be public or private.

[0123]

[0121] In some embodiments, querying the DL may include, for example, receiving tokens representing an event and / or a pattern, or a portion thereof, enabling reliance without disclosing the underlying data on which the recording of the event or pattern is based.

[0124]

[0122] In some embodiments, there may be local ledger nodes operated, for example, by a person under surveillance, a facility, an insurance or other service and / or product provider. In some embodiments, tokens may have specifications and / or smart contracts for those tokens and may include specifications based on proximity in that specific conditions for the proximity of the tokens may be implemented.

[0125]

[0123] In some embodiments, a person under surveillance in a monitored environment may have data generated by sensors processed by a care processing system using a protected processing environment, the environment being generated by the sensors, processed by the care processing system, communicated by one or more digital twins, and communicating with the one or more digital twins such that data acted upon based thereon is always protected. For example, the digital twin may incorporate the digital twins of the sensors that monitor the person under surveillance, their environment, and the care processing system, such that the data supplied by the physical sensors that monitor the person and environment under surveillance is represented by the digital twin. Relationship between the protected processing environment and at least one DL In some embodiments, the data from the sensors may be available only to specific stakeholders in specific situations, while on the other hand, the sensor data may need to be available for the digital twin to represent the person under surveillance and their environment. The security of the data is maintained by a protected processing environment for connecting and communicating between the physical person under surveillance, the sensors of their environment, the care processing, and the digital twins that represent these entities.

[0126]

[0124] FIG. 21 shows a person under surveillance in a monitored environment (101), with sensors (2101) performing the monitoring and providing data to a care processing system (2102). In this example, the care processing system provides such data through a protected processing environment to one or more digital twins (701) that include at least a partial digital twin representation of the sensors (2105) and care processing (2106) to represent physical equivalents. For example, the protected processing environment may then store the data, processing, and other metadata in a distributed ledger. This can include the use of tokens.

[0127]

[0125] Token interaction

[0128]

[0126] In some embodiments, the sensor may generate a token representing one or more data sets. For example, this may be an event detected by the sensor and may include a set of features recognizable by such a sensor. The creation of such an event can be such that the token contains data that can only be created by such a sensor having such an issuing ability, such as a server, router, switch, care hub, or other device and / or service capable of creating such a token, at least one location, within a specific time range, and interact with either the device or the networked issuing function in a secure manner.

[0129]

[0127] In many situations, the token can be generated by at least one event, for example, this may include visits by caregivers / family members of other relevant parties, device startup events, sensor startup events, etc.

[0130]

[0128] The tokenized information can notify one or more relevant parties without providing the underlying highly confidential care and health information of the monitored person. The distribution of the information represented by the token can be controlled by the token itself, and the ID of the relevant party, including their role in the care village, can determine how accessible the token data is. Also, data distribution may be controlled by a cloud or other service that extracts data from the token using relevant authentication information or converts the token into another token for a specific relevant party. This service can directly notify the relevant party of the token data. The service may provide such data through a reference or, for example, by embedding it in a further token.

[0131]

[0129] By using services that can accept, redeem, and / or issue tokens, a mediated data exchange format can be provided to a series of stakeholders that enables each stakeholder to access data related to the situation and context without compromising the privacy of those stakeholders and / or the service. This can be in the form of token exchange where a token having a plurality of data sets, for example specific authentication information required to access such data, can be split into individual tokens representing the authentication information requirements associated with a single data set. For example, if a token includes a number of data sets, such as data sets created by one or more sensor sets, such data sets can be distributed to a specific stakeholder and each stakeholder can access the data for its specific purpose.

[0132]

[0130] Sensors, devices and / or systems can be represented by one or more tokens and interact with other system elements via these tokens. Such tokens can represent data from such sensors, devices and / or systems, commands, configurations, and / or other specifications that can manage, direct, and / or change the operation of those sensors, devices and / or systems.

[0133]

[0131] In some embodiments, the sensors, devices and / or systems may accept only specific tokens, represent a set of specifications, the ID of the token provider is part of the token, and the one or more data sets represented by the token are organized in such a way that only a specific sensor, device and / or system and / or class of sensors, devices and / or systems can interpret the one or more data sets.

[0134]

[0132] In some embodiments, the device and the related party may have a static or dynamic relationship. For example, the related party may have another device such as a smartphone that they own and control, or a sensor that can create data about themselves. Tokens are used to represent these relationships so that the separation of ownership, use, data creation, and / or data distribution can be represented by one or more tokens.

[0135]

[0133] Access to and use of the tokens can be managed by multi-factor authentication or one or more biometric authentications.

[0136]

[0134] Tokens and Rights

[0137]

[0135] The issuance of tokens may, for example, result in the instantiation of tokens created as a result of events, patterns, and / or other occurrences, and the storage of those tokens may be restricted to the sensor, device, and / or system, or a device and / or repository that securely manages them on their behalf. Token distribution, including the rights required to access at least one dataset represented by the token, may be subject to further tokenization of those rights.

[0138]

[0136] The configuration of one or more sensors, devices, and / or systems may include one or more sets of specifications that determine, in whole or in part, the issuance of tokens by those sensors, devices, and / or systems, including the sensor, device, and / or system ID, the distribution of those tokens, and any processing of those tokens.

[0139]

[0137] For example, a set of devices may create a set of tokens based on, for example, an operating pattern and based on the representation of that pattern. This may be applicable when the pattern is static and the care state of the person being monitored does not change. The recording of this data may be used, for example, by one or more digital twins, and the characteristics that can identify changes in the care state of one or more persons being monitored by evaluating and comparing this data with data from other persons being monitored can be determined.

[0140]

[0138] In some embodiments, a session token, i.e., a token created at a specific location during a specific period and / or potentially involving specific stakeholders, may be created. For example, such a token may have specifications where the presence of one or more stakeholders is detected within a specific period and / or at a certain location, for example, by an edge sensor. One or more sensors can be configured to use this token data to generate one or more data sets representing the verification and / or confirmation of the presence of a specific stakeholder and / or the confirmation of the location, and events, actions, responses, and / or activities that occur during the specified period can be made to result in the issuance of one or more session tokens. This may include one or more locations including access to data, one or more sensors, devices, and / or system configurations, other sensors, devices, and / or systems, one or more processing systems, and / or care and health services and functions that support the care and health of the person being monitored.

[0141]

[0139] For example, a person being monitored can receive a specific prescription, procedure, and / or other care and health resources only when, for example, they are in a specific location and / or are in contact with a specific stakeholder within a specific period via a secure communication system. Such proximity or contact can be determined by the co-location of one or more devices representing such persons being monitored, stakeholders, and / or locations, including sensors, devices, systems, and / or services.

[0142]

[0140] For example, one or more session tokens can include specifications, such as rights, authorizations, program materials, such as smart contracts, etc. associated therewith. In some embodiments, such specifications can have one or more temporal constraints, limitations, and / or thresholds, and can enable actions, events, and / or responses by one or more parties, including roles having multiple parties. In some embodiments, if, for example, multiple parties are present, or in contact, and / or such session tokens are required to be provided, a set of session tokens may be required to initiate actions, events, and / or responses. This may apply, for example, when important financial, care, health, and / or legal measures, events, or responses are being carried out.

[0143]

[0141] FIG. 9 shows a person being monitored in a monitoring environment (101), where one or more devices (907) comprise sensors (902) that at least partially generate data (903), which is then securely communicated to a token service (904). In this example, the token service generates a token (905) that is communicated to a care processing system (504), and can call a machine learning and AI module (901) and / or a digital twin (701) in any arrangement. The care processing system can call and instruct a response system (906), and then the response system can provide one or more responses to the person being monitored and / or other parties regarding the environment (101) under surveillance.

[0144]

[0142] Tokens may represent a set of specifications that have different actions and / or results based on the context of the token, including those that indicate rights. For example, in a situation not designated as an emergency in caregiving, a token can enable a set of devices, sensors, related parties, system elements, etc. to utilize set of specifications (A). However, in a situation designated as an emergency in caregiving, such a token can enable set of specifications (B). For example, set of specifications (A) is a subset of set of specifications (B), and set of specifications (B) provides additional specified rights to one or more specified related parties and / or third parties. In some embodiments, such third parties may have their own set of tokens.

[0145]

[0143] The determination of a situation, such as a situation where an emergency or other caregiving event is occurring, can be represented by at least one pattern operating at that time. Such a pattern can include the supply and use of tokens in any arrangement. For example, the pattern can include tokens held by sensors, devices, systems, and / or related parties, etc., which are part of such a pattern. Also, the pattern can include other tokens that can be made available to specific ones among sensors, devices, systems, and / or related parties, etc., which are part of that pattern. In this way, for example, a device may receive a token that changes the configuration of the device when processed by the device, and additional data and / or control of the device may be passed to other system elements, related parties, devices, and / or sensors.

[0146]

[0144] For example, in a situation represented at least in part by one or more patterns, a party A having ownership and control through either a reference to or an embedding of token A1 may provide a dataset A1.1, which is all or part of the dataset of token A1, to one or more other parties, sensors, devices, and / or systems. In a second example situation, which may be represented by the same or different patterns, such a token A1 may provide a second dataset A1.2 to the same or different parties, devices, sensors, and / or systems in any arrangement. The datasets A1.1, A1.2, and any other datasets managed by that token may be in any arrangement, including, for example, subsets, supersets, hierarchies, taxonomies, and the like.

[0147]

[0145] There may also be location-based determinations, for example, called by patterns and / or other sensors, devices, and / or system elements. For example, token A may provide dataset A1.3 if party C is present at the location of token C.

[0148]

[0146] The relationships between tokens can be dynamic and / or pre-determined. Tokens may also have different IDs, such as classes, and the class of a certain type of token may provide all the data that can be provided to the devices, sensors, systems, and / or parties having tokens of the related type to enable such occurrences.

[0149]

[0147] In some embodiments, the set of tokens may need to be made available for data to be used and for events, results, responses, and / or other actions to occur by one or more stakeholders, sensors, devices, and / or systems. This may include, for example, tokens having a number of data sets, each data set being at least partially separated and an authorized issuance service such as a token service module being used. For example, such a service may include a plurality of data sets, may receive a multi-segment token based on a specification, and may then break down such a token into separate tokens for distribution to different stakeholders, devices, sensors, and / or systems.

[0150]

[0148] For example, multi-segment token A includes data set A1, A1.1 is a subset of set A1, token A also includes data set A1.2, A1.2 is a subset of data set A1, and A1.3 is a further subset, and so on.

[0151]

[0149] Token set H may include (J, K, L, M), and each of these tokens incorporates a part of the overall specification represented by token H.

[0152]

[0150] In some embodiments, establishing trust between entities, whether they are stakeholders, systems, devices, or other care village IDs, can be instantiated through the use of tokens. For example, as shown that the relationship between two devices is trustworthy, the two devices may instantiate a token and pass this token to each other. This can be embodied using PKI or other encryption techniques. Another example can be the proximity of one token, for example, a token within a smartphone with a proximity application, and by detecting another device having an appropriate token, the data from that device can be determined to be trustworthy.

[0153]

[0151] This can be applied to interested parties who can specify that the data from the device can be trusted within the scope of the agreement's specifications, because the dataset provided by the device can be verified and the device can be designated as trustworthy.

[0154]

[0152] Conversely, for example, in the promotion of products or services and the transmission of data from a specific perspective, many data sources may be provided to the person being monitored. The same applies when these devices do not have a trust relationship with the person being monitored and their devices.

[0155]

[0153] Interested parties can establish a trust relationship with the device by using biometric authentication and / or multi-factor authentication, etc. The nursing village may provide a token incorporating the unique ID of the device and / or the interested party to enable participation in the nursing village.

[0156]

[0154] Token and ID

[0157]

[0155] The token may represent one or more IDs in the nursing village. This can include system elements in any detail and / or interested parties in any agreement. In some embodiments, the identity of interested parties, including individuals and organizations, may be based on multi-factor authentication such as biometric authentication, devices, tokens, etc. in any agreement.

[0158]

[0156] Each person being monitored and their living environment can have a unique identifier for participation in the nursing village, similar to other interested parties in the village. Multiple ID schemas may be used in such an agreement so that each ID can be represented by at least one token.

[0159]

[0157] In some embodiments, the person being monitored or their authorized proxy may be issued the ability to create tokens that can form part of a set of tokenized data that can represent events, actions, situations, responses, conditions, transactions, time periods, or any other dataset within the care village, by attachment, association, reference, embedding, or other means.

[0160]

[0158] In some embodiments, the IDs of the stakeholders, sensors, devices, and / or services or other system elements may include multiple elements such as biometric and / or other authentication from one or more stakeholders, device-specific UIDs and / or other identifiers, endpoints, and / or service IDs including other registered and authenticated service identifiers represented by one or more tokens. These ID factors can then be combined in any agreement with other specifications, such as time, location, matching, and co-executing system elements (including other stakeholders and / or devices), and represented by one or more tokens.

[0161]

[0159] Often, proximity can be a factor in determining or contributing to the verification and authentication of IDs through the use of tokens that have a dataset issued only near a specific location or near a specific one or more devices and can only be interpreted by a specific device. For example, this can include session tokens.

[0162]

[0160] In some embodiments, information specific to a particular ID may form part of all tokens issued, communicated, and / or redeemed within the system. For example, if there is a specific area or domain, such as an elderly care facility, only tokens containing the appropriate identifier will be accepted by sensors, devices, systems, and / or stakeholders that include such an area or domain.

[0163]

[0161] For example, a person related to a service provider (SP), such as a representative of the SP, can be a recipient of data created by one or more sensors. In this example, such an SP sends requests to a data provider (DP), such as a sensor, device, system, and / or smart contract representing such, and monitors a person being monitored by referring to or embedding the person in whom data of the person being monitored is generated and / or stored. Sensors, devices, systems, and / or smart contracts of the person being monitored may choose to provide or deny all or part of the data requested by the service provider according to the authentication information with the service provider. This may be dynamic in that in the choice of providing or denying data, it can be determined by the person being monitored, their device, and / or proxy based on the context and / or the data requested. This includes a decision-making process based on specifications and / or the interaction of the person being monitored. In this way, the person being monitored can selectively control the data instantiated by sensors, devices, systems, and / or smart contracts deployed to monitor them, including such data generated by any device under the control of the person being monitored.

[0164]

[0162] In some embodiments, the data provider may have preconfigured endpoints for data, such as a designated care hub, care processing system, and / or other sensors, devices, and / or systems (including smart contracts for example). This can include the service provider, but the data provider configuration can determine that a token can represent data, such as an event and / or action or a set thereof, without the service provider accessing the underlying data of the data provider when the service provider receives a token representing the data. This enables access only to data related to the service provider, ensuring the privacy of the data provider, such as the person being monitored, while supporting the operation of the service provider.

[0165]

[0163] In some embodiments, a data provider such as a sensor, device, system and / or smart contract may sign a message from a service provider requesting data from the data provider. This can be in the form of a signed token, which can include, for example, configuration data that verifies the operation of such a sensor, device and / or system without revealing the data generated by their operation. This can include, for example, a reference to such data stored in an elastic repository, where a care process or other system can determine access rights to that data. For example, a service provider can send the signed token provided by the data provider to one or more other systems including, for example, a care process system, and an authentication module can operate to support the availability of the token data for the service provider to pursue the relevant service provision. Such an approach may be instantiated using a session token that represents time, location, ID, and other significant data regarding the event that generated the data represented by the token generated by the data provider.

[0166]

[0164] In some embodiments, a token service may include a token ID service and can perform one or more processing operations based on the ID of the token. This includes the distribution of these tokens to appropriate endpoints determined by the token ID information. For example, if the ID of the sensor is included as a source in a token from a set of sensors, the token service can determine one or more endpoints of that token in cooperation with a care hub, care process, or other system, such as a device of an interested party. In some embodiments, this can include asymmetric encryption such as public key encryption or other appropriate key schemes.

[0167]

[0165] In some embodiments, various types of off - tokens, such as other tokens as shown in FIG. 3, can be used throughout the nursing home. These include, for example, context tokens and care tokens, although various other token types may be instantiated by the nursing home as needed.

[0168]

[0166] Context tokens represent the context within the nursing home that has existed, currently exists, or is predicted to exist in the future.

[0169]

[0167] Context tokens are evaluated by the receiving - side endpoint and can establish events, actions, and / or other occurrences whose meaning is determined, in whole or in part, by an endpoint that represents the interpretation by the receiving - side party. In some embodiments, a first party receives a context token, evaluates the token's ID and / or data to create an interpretation that includes further token forms, and then sends it to a second party. In this way, the second party can receive only the data determined by the first party and can confirm events, alerts, and / or occurrences without disclosing the underlying data to the second party.

[0170]

[0168] In some embodiments, a first party receives a token without having the appropriate rights or keys to access the token data, and in so doing, the token is passed to a service such as a token service, a care hub, and / or a care processing system that has sufficient rights to evaluate the token and then returns to the first party a further token that can be evaluated by that party and that includes data relevant to that party.

[0171]

[0169] The care token can represent care and / or health status, such as completed care conditions or care transactions. In some embodiments, the care token can represent the completion of a care event, e.g., the completion of a course such as medication, physical therapy, or other therapies. The care token can represent a care state or a combination thereof, e.g., a prescription, a product, and / or a service request. This includes the ID of the person being monitored and / or other sensors, devices, and / or systems that are proxies for the person being monitored, and provides, in part, an accurate verification of the ID of the care token owner. For example, this may be in the form of a bearer token that is biometrically and / or otherwise coupled to the token holder, e.g., the person being monitored. In some embodiments, the care token can be traded in the care village market.

[0172]

[0170] There can be classes of tokens that can be combined in any arrangement. One form of embodiment can be the use of set theory for the combination and manipulation of tokens.

[0173]

[0171] In some embodiments, the ID information can be stored in at least one distributed ledger and / or its proxy. In this way, an immutable record of the ID can be established, similar to various HCPs, patterns, events, and other data that are fragments of that ID.

[0174]

[0172] Token application

[0175]

[0173] In some embodiments, the detection of events and / or patterns in an environment can generate one or more tokens, which can be passed to one or more devices within and / or remote to that environment, as well as to relevant parties involved in the care and health of the person being monitored in that environment.

[0176]

[0174] These tokens may include multiple datasets and, in some embodiments, may include time or other specifications that can be accessed in an ordered and prioritized manner by sensors, devices, systems, and / or individuals who receive these tokens.

[0177]

[0175] For example, a caregiver may receive a token warning of an event and a triage operation being performed in the environment (e.g., where a suspected fall is being evaluated). When the evaluation is made, the token may release further details held by the token by referring to or embedding the event, the individual, and subsequent actions to resolve the situation. In this way, a series of states may be created, which may be represented by a set of tokens, each set being part of a pattern that unfolds to match data patterns detected from the person being monitored and the person doing the monitoring.

[0178]

[0176] In some embodiments, a token may have a data payload that requires multiple devices to cooperate in a specified manner to access the data. For example, a first device generates one or more tokens and the first device sends one or more tokens to a second device. The second device receives one or more tokens and the second device is configured to interpret a subset of the token data. Such a second device may request, and / or be configured, and / or be instructed to connect to the first and / or third devices to perform at least one operation based on the configured access to the data within the token.

[0179]

[0177] In this way, the third device may operate to instruct and / or configure the second device without the second device accessing the data held by one or more tokens.

[0180]

[0178] Tokens or sets thereof can represent events (plural possible), actions (plural possible), responses (plural possible), patterns (plural possible), and / or other occurrences, and when passed to appropriate devices and / or systems, such devices and / or systems can employ one or more processing units on that data to verify events (plural possible), actions (plural possible), responses (plural possible), and / or patterns (plural possible). This can be in the form of one or more tokens representing such verification, although the one or more tokens need not reveal the data of that verification.

[0181]

[0179] In some embodiments, a gamification “token set” can include user event sequence tokens that include one or more tokens representing, for example, patterns, and can be used to represent positive / negative care and health activities. For example, a pattern that includes an exercise event sequence can have tokens that represent that portion of the pattern that is passed to a gamification engine that displays the benefits and metrics of such exercise in a way that is beneficial for care and wellness. A similar approach can be used for activities that can have an adverse effect on health, such as, for example, not moving for long periods of time. The representation of these care and health metrics is suitable for gamification, and for example, instantiations that employ Unreal Engine or Unity as a game engine can be used, but using tokens as a data providing mechanism and in some instances as a game incentive mechanism can provide significant benefits to the user, such as enabling selective access to these data sets in the context of the privacy of the person being monitored.

[0182]

[0180] Tokens and environmental sensing

[0183]

[0181] In some embodiments, one or more tokens can be used for inter-sensor and intra-sensor, device, and / or system communication. These communications can be in the form of tokens representing a particular dataset, i.e., events, actions, responses, sensor detections, patterns, and / or similar representations such that the source of such data is recognizable by the recipient. This can be an ID that provides sufficient information to identify the originator of the token and the event, action, pattern, detection, or other change in the sensor state.

[0184]

[0182] In this way, data may be transferred from one entity to another, such as from a sensor, device, system, or other entity, without compromising the privacy of the source, and can convey sufficient data to perform appropriate actions, processing, configuration, or other activities.

[0185]

[0183] The placement of such networks of sensors, devices, and / or systems may be preconfigured and / or dynamically instantiated. This is particularly important in cases of severe care situations where data transfer from one set of sensors, devices, and / or systems to another may be important for the health of the person under monitoring.

[0186]

[0184] Tokens may be communicated between sensors, devices, systems, and / or other system elements and can represent datasets held or managed within or by such sensors, devices, systems, and / or other system elements or within a proxy such as a distributed ledger. Tokens may cause specific activities to be executed or invoked by such sensors, devices, systems, and / or other elements of the system.

[0187]

[0185] In some embodiments, the set of sensors may detect changes in the state of the environment, including the person being monitored, and each sensor may then generate a state change token that can represent, for example, a particular change detected by the sensor. These representations of changes may be held in one or more repositories, and the changes in state can form part of a pattern specification, pattern elements, or other organization of data. There is a set of conditions, and when satisfied, further tokens are generated and can be communicated to one or more sensors, devices, systems, and other elements. Such tokens may cause a change in configuration to these, for example, through tokens that represent IDs and / or values that sensors, devices, systems, and other elements can be embedded with or interpreted as specifications by reference.

[0188]

[0186] One aspect of the system is to monitor a person being monitored in an environment (often their place of residence) using sensors. These sensors can be configured to provide data in a form such as a token that can be partially or fully evaluated by one or more processors to establish a relationship between the token and the behavior pattern of the person being monitored. This can be achieved, for example, by incorporating program processing into the sensors to convert raw sensor data into a form that can be evaluated within a pattern, while still maintaining the privacy of the person being monitored. For example, in the case of a camera, the arrival and sitting of a person being monitored in a certain area (e.g., the living room) can be represented as a token and as a behavior that forms part of a pattern element without the image capture of the person being monitored being transferred to any repository configured by pattern monitoring or other system elements.

[0189]

[0187] In some embodiments, this image data may be retained for a period of time by the sensor or its proxy, such as a secure digital twin, if the person being monitored undergoes a health event for which such an image may be notified, otherwise the image is deleted. In this way, the pattern of behavior of the person being monitored is maintained, as is the privacy of the person being monitored.

[0190]

[0188] Tokens can be used for configuration and / or data. In some embodiments, this can be formed as a separate token type and / or multi-part token that includes both configuration specifications and data.

[0191]

[0189] Tokens may represent one or more events including their set, which can communicate with other system elements such as, for example, a care process system, other sensors, devices of interested parties, and / or one or more authorized digital twins.

[0192]

[0190] In this way, the data of the event and the token representing the event can be separated, and patterns or other system elements can utilize the tokens and the states of the events they represent without accessing the underlying data, thus protecting the privacy of the person being monitored and / or other interested parties.

[0193]

[0191] Thereby, the system can verify that a specific event has occurred while maintaining the privacy of the person being monitored and / or other interested parties. In some embodiments, there may be multi-layer tokens, for example, in a device including one or more sensors, a network device connecting a set of sensors, such as a care hub, and / or another authorized proxy for one or more sensors, the issuing service generates a multi-layer token at the source. Such a multi-part token may include a framework that is partially input by data generated by one or more sensors, and additional data may be added to the token framework as this multi-layer token traverses the system. This can also include the evolution of the input portion of the token by such system elements, as a result additional data is input into the token and / or such data may be used for one or more other system operations.

[0194]

[0192] In some embodiments, tokens can be organized, for example, into an ontology, taxonomy, or other convention. For example, there may be a hierarchy of tokens that can be issued by one or more sensors, devices, and / or systems, for example, such a hierarchy being based on the severity of the sensed state determined by arbitrarily arranged sensors, devices, and / or systems. A further example can be the arrangement of tokens for one or more sensors, devices, and / or for the configuration of sensors such that various degrees of a configuration, such as fidelity or detail, are arranged in a hierarchical aspect of the tokens.

[0195]

[0193] This can include using pre-formatted tokens that are, for example, based on type, ontology, and / or taxonomy, such that sensors, devices, and / or systems can utilize such tokens from, for example, a local or remote repository. This can be beneficial when there are constraints on battery power and other important functions. There may also be pre-formatted tokens that represent complex relationships between sets of sensors, such as those of a multi-dimensional feature set, for example, one or more pre-formatted tokens may be issued by a service, such as a care processing service, that represents the type of fall event, if a set of thresholds and / or relationships are reached or exceeded. Such a set of tokens can be communicated to appropriate parties instead of potentially numerous individual state change tokens that form a set of sensors, devices, and / or systems.

[0196]

[0194] In some embodiments, a pattern and / or a pattern element can have tokens representing one or more states of the pattern and / or the pattern element, such as a static token, a state change token, a sensor state token, a sensor configuration token, and / or tokens representing one or more events, actions, and / or responses. For example, a monitored person going to bed for sleep at night may have tokens presenting the pattern and / or the pattern element, and can notify the care processing system of the state through the tokens. Such an approach ensures that the underlying data of the monitored person is not revealed to the care processing system or other monitoring systems, while such systems are reliably notified of the state of the monitored person. In some embodiments, one or more sensors, devices, and / or systems can maintain data sets they sensed, for example, in one or more elastic repositories. In some embodiments, when issuing tokens, the sensors, devices, and / or systems directly or indirectly continue to sense the environment and store the sensed data in the elastic repository if such data can be evaluated, for example, by a care processing system.

[0197]

[0195] Except in cases of important health or care needs such as emergencies, using tokens representing a set of one or more patterns and / or pattern elements without revealing the underlying data enables an effective monitoring function while ensuring the privacy of the monitored person and other related parties.

[0198]

[0196] In some embodiments, a processing system, such as a care processing system, for example, can evaluate the state variation of a multi-dimensional feature set through, for example, comparison of a set of dimensions. This can include evaluation of a data set including such dimensions and can be invoked through one or more issued and / or processed tokens. For example, when a sensor, device, and / or system issues a token representing a change in the state of that sensor, a processing system such as a care processing system can be initiated to evaluate the dimensions of the multi-dimensional feature set to which the data from that sensor, device, and / or system contributes. This may include evaluation of a set of dimensions related to the dimension to which such data belongs.

[0199]

[0197] Such evaluation can represent changes in care and health states represented as behavior patterns through interpretation of the feature set data. In some embodiments, this can include static and dynamic analysis of the multi-dimensional feature set to create a quantized interpretation, including those involving machine learning and AI techniques. These interpretations may not necessarily be deterministic and may be based on fuzzy logic or other approximation methods.

[0200]

[0198] Pattern, pattern element, token

[0201]

[0199] One advantage of the use of tokens is the ability to represent any complex data set, including structured and unstructured data. This can include representation of patterns and / or pattern elements, and tokens can represent patterns and / or pattern elements, such as the stationary state of a pattern of a person during state monitoring of a pattern or pattern element in the context of an HCP, for example.

[0202]

[0200] In some embodiments, tokens representing patterns may be passed to the digital twin, which may receive a plurality of tokens representing similar or identical patterns of a plurality of monitored individuals operating in a particular HCP. Thereby, a machine learning system corresponding to the digital twin can analyze a plurality of data sets without compromising the privacy of a particular monitored individual.

[0203]

[0201] Tokens can represent an operation set that can be a pattern element including those representing a transition from the state of one pattern element to the state of another pattern element. In some embodiments, these tokens may be of a particular class, such as state change tokens, for example, and can represent a change from a stationary state to an activated care and health state. For example, if the HCP is a memory degradation HCP, these tokens may be further organized within a particular HCP such that a state change token can be instantiated when there is a change in the memory ability of a monitored individual that exceeds one or more thresholds, such as thresholds of a multi-dimensional feature set. When these tokens represent a stationary state of a pattern and / or pattern element, they are accumulated and can be used in the metrics of a set of monitored individuals to establish a prediction as to whether and when a transition state, also represented by the token, is likely to occur.

[0204]

[0202] Focus by various prediction - stakeholder types (such as comfort / health and risk) from a single token to multiple stakeholders

[0205]

[0203] One aspect of the system is a combination of tokens that aggregates and creates a history regarding events, actions, responses, data, stakeholders, timing, pattern elements, patterns, and / or other system elements. For example, tokens from sensors are processed by the care of other processing systems that have a known relationship with that token at a consistent point in time for both the sensor and the processing, and can form part of a pattern that operates as part of the HCP of the person being monitored. Then, this data can be used to confirm or verify the actions of one or more stakeholders who were present in the presence of the sensor at the time the sensor provided the data and the care or other processing manipulated the data as part of the pattern.

[0206]

[0204] A further type of history of all aspects of the system, including sensors as senders of data, actions, events, patterns, transformations, and other static and dynamic elements, can be represented with varying degrees of credibility.

[0207]

[0205] In some embodiments, a series of actions and / or events involving a stakeholder, such as a person being monitored, can be represented as a set of tokens. For example, if there is a specific series of actions for the person being monitored, such as performing a routine of exercise, breakfast, using the bathroom, and reading at a certain time period when waking up, this dataset can be represented by at least one token. In this way, the efficiency of processing data regarding the person being monitored, including privacy, can be significantly improved.

[0208]

[0206] The set of tokens can be an arbitrarily complex combination, and for example, at least one token set can be combined with another token set to form a new set that represents behavior that is at least partially common across a number of HCPs and / or persons being monitored within that pattern. The set of tokens can represent a certificate of a particular behavior, treatment, action, event, or other combination that complies with one or more specifications, such as the specifications of the pattern.

[0209]

[0207] Token trading

[0210]

[0208] In some embodiments, the token can be used as a medium for communication involving transactions among multiple parties, including sensors, devices, interested parties, and / or systems. There may be types of tokens specific to different types of transactions. For example, one type of token may be used for transactions having an ultimate monetary value, another type may be used in datasets specific to caregiving or health, and / or another type may be used for sensors, devices, and / or system data that is essentially information.

[0211]

[0209] In some embodiments, this can include, for example, digital currency tokens that are available in a broader context such as Bitcoin, and / or those specific to certain areas such as elderly care facilities, insurance operating systems, care villages, local neighborhoods, etc. This can include various types of value representations including fiat currency and sovereign currency, virtual currency, royalty or other reward schemes. For example, neighbors may accumulate "care points" represented as tokens for activities such as supporting a person under surveillance.

[0212]

[0210] The market for such tokens can be set up and operated on any scale within care villages, medical facilities, neighborhoods, agreements among interested parties, and / or any other group where token exchange can be transacted.

[0213]

[0211] In some embodiments, a dataset may be adopted as a representation of proof of actions, events, timing, behavior, interactions, etc. For example, this can include events, sequences of events, satisfaction of specifications, etc. This may include the use of preconditions and postconditions of such specifications, which can be represented in whole or in part by tokens.

[0214]

[0212] Tokens can be aggregated, for example, into a set of tokens representing multiple events, proofs, values, etc.

[0215]

[0213] In some embodiments, the token market may include a matching system that, for example, matches bid or request tokens to offer tokens. This can include probabilistic-based matching, fuzzy logic, constraint analysis, and may include the use of smart contracts and / or other program elements. For example, tokens can represent offers (offers by parties including specifications to be met), bids (bids to meet all or part of the offer specifications). This can include multi-part tokens with increments of satisfaction, where additional informational and / or transactional details become apparent as each specification is met. These multi-part tokens can form a kind of triage where multiple bids are initially accepted and each receives further specifications for satisfaction until related bids are accepted. In some embodiments, a token matching service may be called to perform this process. In another embodiment, this may be done in the form of multi-part tokens by the parties' devices. In situations where this occurs, for example, between two or more sensors, such multi-part tokens may comprise data and configuration specifications.

[0216]

[0214] FIG. 14 shows a simplified example of a market where a party (1401) seeking a product and / or service can create one or more tokens (1403) representing those requirements and communicate them to a market (1407) configured to receive such tokens using a suitable device (1404). In this example, a second party (1402) that is a provider of the product or service can create one or more tokens (1406) representing such services and communicate them to the market using a similarly suitable device (1405). In this example, the market (1407) includes a matching module configured to at least partially match the requested service and / or product to the offered service and / or product that meets the requirements.

[0217]

[0215] Within the overall system, any one of system flow, event, transaction, process, request, etc. can be represented by a token. These tokens may be individually and aggregately exchanged with other tokens in any arrangement. For example, a token may form part of an event sequence (e.g., a task flow, etc.), a token may represent a complete sequence or a part thereof, and a token may be exchanged and / or converted into, for example, value (such as fiat currency, digital currency and / or sovereign currency or other acceptable value), confirmation, verification, authentication or other message, event, action and / or trigger, and one or more representations of other tokens / messages.

[0218]

[0216] In some embodiments, tokens can be typed and may be part of a classification schema, and such a schema can have conditions and specifications that govern the operation of such a schema in at least one context.

[0219]

[0217] The nursing home market can incorporate any / all stakeholders and their devices and tokens in any arrangement. The market can require that all entities interacting with the market have a valid unique ID for the nursing home. In such embodiments, the nursing home may include verification of any obligations, bids and offers, or settlement of other transactions, enabling a verifiable and authenticated audit trail for those transaction activities.

[0220]

[0218] Figure 15 shows an example of a market (1501) that partially includes a matching service (1502) and an agreement on one or more smart contracts and a distributed ledger (1503). In this example, one or more parties (1504 - 1508) create one or more tokens that are communicated to the market via a properly configured device. These tokens can represent any type of data, such as requests for products, services, etc. Such requests can be fully or partially satisfied by one or more providers of products and / or services, such as, for example, an insurance company (1509), a nursing facility (1510), a health and / or healthcare provider (1511), a medical facility (1512) and / or other service and / or product providers (1513). In the illustrated example, the market (1501) may use the matching service (1502) to match requests for product and / or service offerings from the parties (1504 - 1508) with product and / or service offerings from the providers (1509 - 1513). These matches and any subsequent agreements can be recorded in one or more smart contracts recorded in one or more distributed ledgers (1503). The market (1501) may also provide the matching service (1502) to one or more providers (1509 - 1513) under any agreement, and can also match the party services and / or product offerings (1509 - 1513) to one or more providers (1509 - 1513). For example, if a party (e.g., 1507) is a caregiver, they may provide services to a nursing facility (1510) through, for example, the market and the matching system.

[0221]

[0219] In some embodiments, in addition to the unique ID established by the care village for the parties, there may also be memberships for various other organizations of these parties. For example, a family may create a membership for relatives of a person under surveillance, and those members can utilize specific data. This includes various classifications and other organizational schemas.

[0222]

[0220] Such membership can be represented by an open set or a closed set and may include organizational principles such as functions, characteristics, capabilities, context, location, and time considerations.

[0223]

[0221] In some embodiments, such a market may be linked, for example, through at least one API to insurance companies, healthcare providers, and / or other suppliers of products and services.

[0224]

[0222] In some embodiments, tokens may form part of a series of future-looking devices such that, for example, a token can be an option for access to a product, service, party, or other entity. For example, this can include the use of tokens as a means of transfer and / or reservation for bookings, carriers, facilities, equipment, etc. Such an approach can also be used for value-oriented transactions such as health and wellness services including options to purchase insurance, procedure planning, dosing, and experts for such procedures. This can include a marketplace for the circulation of such tokens.

[0225]

[0223] Examples:

[0226]

[0224] A PERS (Personal Emergency Response System) device equipped with multiple sensors such as an accelerometer, altimeter, position information (GPS, Wi-Fi, etc.), Bluetooth, and mobile network functions can detect events and report them as tokens to other devices or servers such as care hubs. These tokens may include sensor data or may reference data stored in the sensors. These other devices in the monitoring environment and / or the server may make decisions regarding event responses, such as escalation, without accessing the information stored or referenced by the tokens. Other devices within the system may obtain the tokens and / or the data associated with the tokens and use that data, for example, to enhance event detection accuracy and / or to confirm events. For example, a PERS device may interpret a combination of acceleration and altitude changes from sensors as a "fall" event (the person being monitored tripped and fell to the floor), issue a token associated with the sensor data, and transmit that event token to the server and nearby terminal devices. The server may initiate a notification to a call center or a smart speaker app to start a conversation with the person being monitored, while the nearby terminal device may combine the PERS sensor data with data from its own sensors (audio signals from a microphone or microphone array, output signals from one or more FMCW radar sensors, etc.), request event data from the PERS device, and use that data to confirm the fall event and / or add accuracy using a token combined with an ID or other authentication key.

[0227]

[0225] The PERS device may issue tokens that, when combined with tokens or data from other devices, can create evidence of interactions, for example, of a person under monitoring, a caregiver, and / or other relevant parties. For example, a caregiver may use a smartphone app that connects to the PERS device. The connection may use Bluetooth, ensuring that it occurs only when the caregiver is near the PERS device and thus near the person under monitoring carrying the PERS device. Through the connection, the PERS device may transmit a token that uniquely identifies the device and may include additional device and / or sensor data. This token can be used as evidence that a scheduled visit by the caregiver to the person under monitoring occurred at a specific time and location. The token may be combined with tokens from other devices to create proof that a treatment or series of tests expected / scheduled for the person under monitoring, such as medical sensors and other medical devices, was carried out. The combination of tokens may occur within the device where the activity occurred or at different locations and times within a server or end device. In either case, the combined token and the resulting "token as evidence" can be stored in the DL, and the processes of verification, combination, and issuance of proof can be executed with smart contracts that help improve privacy and reduce the risk of fraud.

[0228]

[0226] In some embodiments, the token service provides token issuance, exchange, and / or redemption functionality to one or more system elements. These functions can include the management and storage of such tokens and include one or more encryption services including token ID management systems and key management.

[0229]

[0227] The token service may include any combination of these functions. For example, a token service instantiated as part of a care hub may include these functions and additional device-specific functions.

[0230]

[0228] In some embodiments, an instance of the token service may issue a token having certain identification characteristics, such as an identifier including, for example, at least in part, a cryptographic reference within a specific range. For example, a set of computationally secure tokens may be used in an environment where access to the environment is restricted to specific authenticated sensors, devices, and / or systems embedded within the environment. When the token service interacts via a network connection that includes an external connection to the environment, informationally secure encryption techniques may be employed.

[0231]

[0229] All or part of the token service may be instantiated as hardware using a protected processing environment, such as off-the-shelf components available from Intel, ARM, AMD, etc., or as a custom hardware design or one that includes a secure coprocessor such as an Apple unit.

[0232]

[0230] The token service may include one or more anti-tampering techniques, such as deleting the secret key held by such a device when detecting tampering, such as an attempt at side-channel access.

[0233]

[0231] In some embodiments, different types of tokens may be issued by a special token service. For example, a data token may be issued by a token service that is part of a sensor, device, and / or system, and that token service has only the ability to issue such data tokens, and the token itself includes the sensor ID and encrypted data generated by the sensor. These are described herein as lightweight tokens.

[0234]

[0232] A further example may be, for example, that a sensor, device and / or system issues one or more configuration tokens that are propagated to one or more other sensors, and upon receiving such tokens, a token service for configuration tokens modifies their configuration using the configuration data within the tokens. This can include one or more specifications regarding the communication of a dataset generated by a sensor after the received configuration has been implemented by the sensor. For example, if a camera sensor is configured to record captured images and store such images in a specified elastic repository, these images may be used by a care processing system to evaluate whether a monitored person has fallen or simply tripped. On the other hand, in the normal operation of such a camera, only the edges of the images are detected and compared with known horizontal and vertical planes of the environment to detect a sudden change in the orientation of the subject of the image capture, such as a monitored person.

[0235]

[0233] In some embodiments, the token service may issue NFTs (non-fungible tokens) representing events and / or event sequences and may involve multiple stakeholders over a period of time. For example, when many stakeholders are involved in a series of events, such as when a monitored person transitions from one movement pattern to another, this change in movement can be represented by an NFT. The NFT may include a dataset that can be evaluated by one or more care processing systems. For example, the data can be compared with the transition patterns of other monitored persons with similar care and health conditions without revealing any PII of the original monitored person.

[0236] NFTs and other token types, as representations of a person's data being monitored, may support one or more ownership relationships of the data in combination with one or more smart contracts. For example, a person being monitored may choose to allow their data to be used in research by an accredited university, etc., while research by a pharmaceutical company, etc., may request it for itself or its agents upon request. In some embodiments, some form of value exchange may be effected between the person being monitored and the user of the data.

[0237]

[0235] In some embodiments, this can include the use of distributed ledgers and smart contracts, at least in part, to support any policies regarding the use of the data.

[0238]

[0236] In another embodiment, for example, a token service may have a limited set of tokens that can be issued by certain sensors, devices, and / or systems, etc., at a specific location, in the presence of one or more stakeholders, over a certain period of time.

[0239]

[0237] In some embodiments, a token service can be instantiated to provide token issuance and / or token redemption. This can include a token service configured to receive tokens from one or more approved token issuance services and exchange them for tokens embedded within a sensor or device that can interpret them. In some embodiments, a token service may comprise separate functional elements such as, for example, token issuance, token evaluation, token redemption, etc.

[0240]

[0238] In some embodiments, a token may provide an audit trail for a series of activities, such as the acceptance of services to a person being monitored, and tokens generated as part of that activity can provide evidence of that activity to the stakeholders, although the data generated by the activity may not be available to those stakeholders. For example, in the case where an insurance company is a stakeholder.

[0241]

[0239] In some embodiments, the token service may support the distribution of tokens to one or more digital twins, such digital twins collaborating with one or more care processing systems to evaluate the potential care and health status of the person under monitoring.

[0242]

[0240] The care hub may form part of a monitoring system for the person under monitoring and their environment. The care hub can function as an intermediary between one or more sensors, devices, and / or systems, functioning between the data generated by those sensors, devices, and / or systems and other sensors, devices, and / or systems capable of communicating that data. In some environments, there may be a care hub that incorporates a token service that forms part of the management, communication, and distribution of these data sets.

[0243]

[0241] Such embodiments may comprise one or more protected processing environments such as Intel SGX, ARM Trustzone, etc., in which key generation, processing, and / or storage may be instantiated. Using a hardware and hardware - compliant token management system can support both data integrity and security. The token distribution specification may include the specification of particular endpoints for the tokens, those endpoints being uniquely configured for such token distribution. For example, endpoints such as the devices of relevant parties such as caregivers may be configured to accept tokens only from a particular care hub and / or particular sensors, devices, and / or systems.

[0244]

[0242] In some embodiments, tokens created by a token service embedded in and constituted by the care hub may include multiple data segments that can be accessed only by designated relevant parties.

[0245]

[0243] Figure 18 shows a care hub (1803) that includes at least partially one or more token service instances (104), a protected processing environment (1801), and a care hub management system (1802). In this example, a set of devices (1804) with a set of sensors (102) is configured to securely communicate that data to a care hub (1803) that generates a dataset (103) and manages that data. The care hub (1803) that uses the configuration and specifications managed by the protected processing environment (1801) and the care hub management system (1802) creates a set of tokens (107) and distributes them to other system elements including a care processing system (504), a digital twin (701), and a response system (902). The care processing (504) and the digital twin (701) may call a machine learning system (901), and for example, data from the machine learning system (901) may also be communicated to the care hub (1803) and then such data may be included as part of the token set (107), for example, in a multi-segment token. For example, this may be the case when a multi-dimensional feature set is used by machine learning (901) techniques to evaluate potential variations in one or more dimensional relationships, and such variations are expressed in a way that can be used to configure one or more sensors, devices, and / or systems to identify such variations in their respective datasets.

[0246]

[0244] Figure 19 shows a set of sensor, device, and / or system-generated datasets (1901) processed into multi-segment tokens (1111) by a care hub (1803), where different datasets are only available to different stakeholders (1108, 1109, 1110). In some embodiments, devices representing such stakeholders may be configured to share such data in an emergency situation such as a medical emergency.

[0247]

[0245] The previous description of the embodiments is provided to enable any person skilled in the art to practice the disclosure. Accordingly, the present disclosure is not intended to be limited to the embodiments shown in this specification, but should be accorded the widest scope consistent with the principles and features disclosed herein.

Claims

1. A system for protecting the privacy of a person being cared for by at least one caregiver, a plurality of environmental sensors configured to monitor the person being cared for and provide a token, the token including a detected data set representing the actions of the person being cared for in the environment, the token being encrypted using an encryption key, and each of the actions being represented by a multi-dimensional feature set forming part of the healthcare profile of the person being cared for; a care processing system, a transceiver configured to receive the token from the plurality of environmental sensors, a token service module configured to decrypt the token using the encryption key, a non-transitory computer-readable storage medium configured to store a static data set, the static data set representing previous static actions of the person being cared for in the environment, at least one hardware processing unit for determining a health or care event for the person being cared for by comparing the token with the static data set, and a care processing system configured to notify the at least one caregiver when the health or care event occurs. A system comprising the above.

2. The system according to claim 1, wherein the encryption key is selected based at least in part on the detected data set.

3. The system according to claim 1, wherein the encryption key is selected based at least in part on the at least one caregiver.

4. The system according to claim 1, wherein the encryption key is selected based at least in part on the person being cared for.

5. The system according to claim 1, wherein the encryption key is selected based at least in part on the type of event detected by the environmental sensors.

6. The system according to claim 1, wherein the encryption key is unique to the session of the person being cared for.

7. A system for safeguarding the privacy of a person being cared for by at least one caregiver, A plurality of environmental sensors configured to provide, by monitoring a care recipient, a detected data set that represents the care recipient's actions in an environment, wherein each of the actions is represented by a multi-dimensional feature set that forms part of the care recipient's healthcare profile. A care processing system, A transceiver configured to receive the detected data set from the plurality of environmental sensors, A non-transitory computer-readable storage medium configured to store a stationary data set that represents previous stationary actions of the care recipient in the environment. At least one hardware processing unit for determining a health or care event for the care recipient by comparing the token with the stationary data set. A care processing system, wherein when the health or care event occurs, a token service module is configured to encrypt a token including the health or care event using an encryption key, and the care processing system is configured to notify the at least one related person. A system comprising the above.

8. The system according to claim 7, wherein the encryption key is selected at least in part based on the detected data set.

9. The system according to claim 7, wherein the encryption key is selected at least in part based on at least one related person.

10. The system according to claim 7, wherein the encryption key is selected at least in part based on the care recipient.

11. The system according to claim 7, wherein the encryption key is selected at least in part based on the type of event detected by the environmental sensor.

12. The system according to claim 7, wherein the encryption key is unique to the care recipient's session.

13. A system for protecting the privacy of a person being cared for by at least one related person, A data repository, A plurality of environmental sensors configured to generate a detected data set by monitoring a care recipient, wherein the detected data set represents the care recipient's actions in an environment, and each of the actions is represented by a multi-dimensional feature set that forms part of a healthcare profile for the care recipient. The plurality of environmental sensors, are further configured to store the detected data set in the data repository, and further configured to provide a data token, the data token including a pointer to the detected data set in the data repository, the data token being encrypted using an encryption key, the plurality of environmental sensors; a care processing system, a transceiver configured to receive the data token from the plurality of environmental sensors, and a token service module configured to decrypt the pointer from the data token using the encryption key, the transceiver being further configured to receive the detected data set specified by the pointer from the data repository, a non-transitory computer-readable storage medium configured to store a static data set, the static data set representing previous static actions of the care recipient in the environment, the non-transitory computer-readable storage medium; at least one hardware processing unit for determining a health or care event for the care recipient by comparing the detected data set with the static data set; a care processing system configured to notify the at least one relative when the health or care event occurs; A system comprising.

14. The system according to claim 13, wherein the data repository stores the detected data set in a distributed ledger as a blockchain token.

15. The system according to claim 14, wherein the encryption key is selected based at least in part on the detected data set, the at least one relative, the care recipient, the type of event detected by the environmental sensor, or the session of the care recipient.

16. The system according to claim 14, wherein the distributed ledger is a permissioned blockchain.

17. A system for protecting the privacy of a person being cared for by at least one relative, a data repository, A plurality of environmental sensors configured to monitor a care recipient and provide a detected dataset representative of the care recipient's behavior in the environment, each of the behaviors being represented by a multi-dimensional feature set that forms part of a healthcare profile for the care recipient, the plurality of environmental sensors, store the detected dataset in the data repository, a plurality of environmental sensors further configured to provide a pointer to the detected dataset in the data repository, a care processing system, a transceiver configured to receive the detected dataset from the plurality of environmental sensors, a non-transitory computer-readable storage medium configured to store a static dataset, the static dataset representing previous static behavior of the care recipient in the environment, at least one hardware processing unit for determining a health or care event for the care recipient by comparing the token and the static dataset, a care processing system, wherein when the health or care event occurs, a token service module is configured to encrypt a data token including the detected dataset or the health or care event using an encryption key, and the care processing system is configured to notify the at least one related person, A system comprising.

18. The system according to claim 17, wherein the data repository stores the detected dataset in a distributed ledger as a blockchain token.

19. The system according to claim 18, wherein the encryption key is selected based at least in part on the detected dataset, the at least one related person, the care recipient, the type of event detected by the environmental sensor, or the care recipient's session.

20. The system according to claim 18, wherein the distributed ledger is a permissioned blockchain.

Images