WO2022087724A1

WO2022087724A1 - System and method for contact tracing

Info

Publication number: WO2022087724A1
Application number: PCT/CA2021/051502
Authority: WO
Inventors: Marc-olivier GUERIN; Benoît Janvier; Félix GRONDIN; Francis KUS; Dominic THIVIERGE
Original assignee: Enero Inventions
Priority date: 2020-10-26
Filing date: 2021-10-26
Publication date: 2022-05-05
Also published as: CA3199954A1

Abstract

A system for, and method of, contact tracing a user device is provided. The system comprises at least one processor, and a memory comprising instructions which when executed by the processor configure the processor to perform the method. The method comprises sending a user propagation factor value to a hub device, and receiving access notification to the hub based on the user propagation factor value and a threshold value.

Description

System and Method for Contact Tracing

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of United States Provisional Patent Application No. 63/105,405 filed on October 26, 2020, the contents of which are hereby incorporated by reference.

FIELD

[0002] The present disclosure relates to a system and method for contact tracing.

INTRODUCTION

[0003] Different contagious diseases may be transmitted differently. For example, air borne viruses may infect people within a certain vicinity whereas other viruses may require physical contact to be transmitted from one person to another. Different contagious diseases may also have different incubation periods before symptoms are visible. Moreover, a person may be contagious with certain diseases and not know. If an incubation period is sufficiently long, a person may not know that they are infected with the disease (and contagious) and may unintentionally infect another person.

[0004] When an infectious disease is prevalent in a society, it is desirable to have a way in which to contact trace individuals who have been in contact with a person known or suspected to have the disease.

SUMMARY

[0005] In one embodiment, there is provided a system for contact tracing a user device. The system comprises at least one processor, and a memory comprising instructions which when executed by the processor configure the processor to send a user propagation factor value to a hub device, and receive access notification to the hub based on the user propagation factor value and a threshold value.

[0006] In some embodiments, access to the hub is permitted when the user propagation factor value is less than a threshold.

[0007] In some embodiments, access to the hub is denied when the user propagation factor value is greater than a threshold. [0008] In some embodiments, the threshold value is based on an intensity of spreading value associated with the hub.

[0009] In some embodiments, the at least one processor is configured to record at least one of a time of entry to the hub associated with the user device, a time of exit from the hub associated with the user device, or a user client identifier associated with the user device.

[0010] In some embodiments, the at least one processor is configured to send to a public database at least one of the time of entry, time of exit, or the user client identifier.

[0011] In some embodiments, the at least one processor is configured to receive a hub propagation factor value to the user device, and display a hub entry suggestion based on the hub propagation factor value.

[0012] In some embodiments, the at least one processor is configured to generate a user client identifier anonymously associated with the user device, the user client identifier associated with the user propagation factor value.

[0013] In some embodiments, the at least one processor is configured to periodically generate a new user client identifier associated with the user device, and store at least one previous user client identifiers in a memory.

[0014] In some embodiments, the at least one processor is configured to obtain report details from a database, the report details including at least one of an updated hub propagation factor value for each hub in which the user device has frequented over an incubation period, and an indication if any other user client identifier present at any such hub, when the user device was present at that hub, has tested positive, and determine an updated user propagation factor value based on the obtained report details.

[0015] In another embodiment, there is provided a method of contact tracing a user device. The method comprises sending a user propagation factor value to a hub device, and receiving access notification to the hub based on the user propagation factor value and a threshold value.

[0016] In some embodiments, access to the hub is permitted when the user propagation factor value is less than a threshold.

[0017] In some embodiments, access to the hub is denied when the user propagation factor value is greater than a threshold.

[0018] In some embodiments, the threshold value is based on an intensity of spreading value associated with the hub. [0019] In some embodiments, the method comprises recording at least one of a time of entry to the hub associated with the user device, a time of exit from the hub associated with the user device, or a user client identifier associated with the user device.

[0020] In some embodiments, the method comprises sending to a public database at least one of the time of entry, time of exit, or the user client identifier.

[0021] In some embodiments, the method comprises receiving a hub propagation factor value to the user device, and displaying a hub entry suggestion based on the hub propagation factor value.

[0022] In some embodiments, the method comprises generating a user client identifier anonymously associated with the user device, the user client identifier associated with the user propagation factor value.

[0023] In some embodiments, the method comprises periodically generating a new user client identifier associated with the user device, and storing at least one previous user client identifiers in a memory.

[0024] In some embodiments, the method comprises obtaining report details from a database, the report details including at least one of an updated hub propagation factor value for each hub in which the user device has frequented over an incubation period, and an indication if any other user client identifier present at any such hub, when the user device was present at that hub, has tested positive, and determining an updated user propagation factor value based on the obtained report details.

[0025] In another embodiment, there is provided a system for contact tracing at a hub. The system comprises at least one processor, and a memory comprising instructions which when executed by the processor configure the processor to receive a user propagation factor value from a user device, and determine access to the hub based on the user propagation factor value and a threshold value.

[0026] In some embodiments, the at least one processor is configured to permit access to the hub when the user propagation factor value is less than a threshold.

[0027] In some embodiments, the at least one processor is configured to deny access to the hub when the user propagation factor value is greater than a threshold.

[0028] In some embodiments, the at least one processor is configured to determine the threshold value based on an intensity of spreading value associated with the hub. [0029] In some embodiments, the at least one processor is configured to record at least one of a time of entry to the hub associated with the user device, a time of exit from the hub associated with the user device, or a user client identifier associated with the user device.

[0030] In some embodiments, the at least one processor is configured to send to a public database at least one of the time of entry, time of exit, or the user client identifier.

[0031] In some embodiments, the at least one processor is configured to provide a hub propagation factor value to the user device.

[0032] In another embodiment, there is provided a method of contact tracing at a hub. The method comprises receiving a user propagation factor value from a user device, and determining access to the hub based on the user propagation factor value and a threshold value.

[0033] In some embodiments, the method comprises permitting access to the hub when the user propagation factor value is less than a threshold.

[0034] In some embodiments, the method comprises denying access to the hub when the user propagation factor value is greater than a threshold.

[0035] In some embodiments, the method comprises determining the threshold value based on an intensity of spreading value associated with the hub.

[0036] In some embodiments, the method comprise recording at least one of a time of entry to the hub associated with the user device, a time of exit from the hub associated with the user device, or a user client identifier associated with the user device.

[0037] In some embodiments, the method comprises sending to a public database at least one of the time of entry, time of exit, or the user client identifier.

[0038] In some embodiments, the method comprises providing a hub propagation factor value to the user device.

[0039] In various further aspects, the disclosure provides corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods.

[0040] In this respect, before explaining at least one embodiment in detail, it is to be understood that the embodiments are not limited in application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0041] Many further features and combinations thereof concerning embodiments described herein will appear to those skilled in the art following a reading of the instant disclosure.

DESCRIPTION OF THE FIGURES

[0042] Embodiments will be described, by way of example only, with reference to the attached figures, wherein in the figures:

[0043] FIG. 1 illustrates, in component diagram, an example of a contact tracing system, in accordance with some embodiments;

[0044] FIG. 2 illustrates, in a component diagram, an example of a client application, in accordance with some embodiments;

[0045] FIG. 3A illustrates an example of a user ID, in accordance with some embodiments;

[0046] FIG. 3B illustrates another example of a user ID, in accordance with some embodiments;

[0047] FIG. 3C illustrates an example of user devices exchanging propagation factors associated with the devices, in accordance with some embodiments;

[0048] FIGs. 4A and 4B illustrates examples of manual check-in contact, in accordance with some embodiments;

[0049] FIGs. 5A and 5B illustrate examples of Bluetooth™ and proximity contact, in accordance with some embodiments;

[0050] FIG. 6 illustrates an example of a GPS contact, in accordance with some embodiments;

[0051] FIG. 7 illustrates an example of a database, in accordance with some embodiments;

[0052] FIGs. 8A and 8B illustrate, in component diagrams, examples of client-to-client contact options, in accordance with some embodiments;

[0053] FIG. 9 illustrates, in a component diagram, an example of a data analysis process, in accordance with some embodiments; [0054] FIG. 10A illustrates, in a flowchart, an example of a method of generating a contact entry log, in accordance with some embodiments;

[0055] FIG. 10B illustrates, in a flowchart, another example of a method of generating a contact entry log, in accordance with some embodiments;

[0056] FIG. 11 illustrates, in a flowchart, an example of a method of generating a report entry log, in accordance with some embodiments;

[0057] FIG. 12A illustrates, in a flowchart, an example of a method of updating a PF, in accordance with some embodiments;

[0058] FIG. 12B illustrates, in a flowchart, another example of a method of updating a PF, in accordance with some embodiments;

[0059] FIG. 13 illustrates examples of client, contact entry and report entry data structures, in accordance with some embodiments;

[0060] FIG. 14 illustrates an example of database interactions for different cycles, in accordance with some embodiments;

[0061] FIGs. 15 and 15A to 15E illustrate, in a component diagram, another example of a contact tracing system, in accordance with some embodiments;

[0062] FIG. 16 illustrates, in a component diagram, an example of a regional database/server, in accordance with some embodiments; and

[0063] FIG. 17 is a schematic diagram of a computing device such as a server.

[0064] It is understood that throughout the description and figures, like features are identified by like reference numerals.

DETAILED DESCRIPTION

[0065] Embodiments of methods, systems, and apparatus are described through reference to the drawings.

[0066] In a disease outbreak, it is desirable to know who are infected with the disease so that these infected individuals may be isolated to prevent further spread of the disease. However, in situations where the incubation period of the disease is long (and the person is contagious during that incubation period), accidental spreading of the disease may occur. Once a person is diagnosed with such a disease, it is desirable to back-trace (e.g., contact trace) where the person has been (and with whom they have been in contact) as far back as the number of days equal to the incubation period prior to when the person first experienced any symptoms (e.g., contact trace period). This would then allow others with whom the person has come into contact to be able to get tested and/or isolate to prevent or slow the further spreading of the disease.

[0067] In some embodiments, there is provided a manner in which to contact trace individuals in a geographic region who are known to be infected, or are likely to be infected, with a contagious disease.

[0068] FIG. 1 illustrates, in component diagram, an example of a contact tracing system 100, in accordance with some embodiments. The contact tracing system 100 comprises a contact recording input component 110, a disease reporting input component 120, a contact tracing database 130, and a disease reporting output component 140. Other components may be added to the contact tracing system 100.

[0069] The contact recording input component 110 comprises at least two client devices 112a, 112b, a contact confirmation unit 114 that confirms that the at least two client devices 112a, 112b have been in contact, and a contact reporting unit 116 for storing contact details in a contact log entry 118 of the database 130. Contact details may include a type of contact (e.g., physical or within a threshold distance), and a duration of time for the contact. The type of contact may be detected via different means. For example, a user of a client device 112a, 112b may self report a contact, use a check-in procedure such as a tap or other near field communication to gain access to an area, a global positioning system (GPS) coordinate comparison, a Bluetooth™ connection, a proximity detection, and/or other types of contact detection. The contact confirmation unit 114 may use such types of contact detection and determine whether or not a contact sufficient enough to (or likely to) spread the disease has occurred. In some embodiments, the type of contact technology used may be associated with a level of confidence of the contact. Other components may be added to the contact recording input component 110.

[0070] In some embodiments, copies of the contact confirmation unit 114 and contact reporting unit 116 may be implemented in a client application on user devices 112a, 112b. FIG. 2 illustrates, in a component diagram, an example of a client application 200, in accordance with some embodiments. The client application 200 may be implemented in a memory and runtime environment of a device 112a, 112b and comprises a user identifier (ID) 210 having at least one of a) a metadata header 220, b) a multi-factor contact-information function 250, and c) external sensor interfaces 270 that are compatible with external sensors. The user ID 210 may be an anonymous, unique identification number associated to the user device 112a, 112b.

[0071] FIG. 3A illustrates an example of a user ID 210 for an individual user 300a, in accordance with some embodiments. In this example, the user ID 300a comprises a type field for identifying the type of identifier being read (e.g., type 001 may designate an individual user, type 002 may designate a type of business, etc.), a revision number field showing the user’s mobile application (e.g., for use in determining if the application is up-to-date), a profession number field for identifying the user’s profession (e.g., indicating a profession group, type or associated risk), an age field for showing the age of the user (note: in some embodiments, this could be a number identifying an age group), a propagation factor (PF) field showing the last- calculated PF, a PF time stamp field indicating the time stamp of the last-calculated PF, and a unique ID field for uniquely identifying the user. It should be noted that this is a simple example of what could be included in a user’s client ID and its metadata header. Additional or different information fields may be included in the user client ID and its metadata header 300a. In some embodiments, the user client ID may simply comprise the PF field and the unique ID field.

[0072] FIG. 3B illustrates another example of a user ID 210 for a hub client ID 300b, in accordance with some embodiments. In this example, the user ID 300b comprises a type field for identifying the type of identifier being read (e.g., type 002 number field may designate a hub type where each of restaurant, bar, stadium, etc., or even a private, temporary, and/or family gathering, may have a different type number), a revision number field used to determine if the hub’s application is up-to-date, a zone field indicating a geographical region of the hub (e.g., province/state, city/town, neighbourhood, etc.), a size field for indicating a size of the hub (e.g., in square meters), a capacity field for indicating a capacity of the hub (i.e. , a maximum number of individuals that can be hosted at the hub), a surge time field for indicating an estimated surge time of the hub (i.e., time with the highest activity), a PF field for indicating the last-calculated PF, a PF time stamp field for indicating a time stamp of the last-calculated PF, a transmission factor field for indicating a last-calculated transmission factor (TF), a TF time stamp field for indicating a time stamp of the last-calculated TF, and a unique ID field for uniquely identifying the hub. Note that this is a simple example of what could be included in a hub’s client ID and its metadata header. Additional or different information fields m may be included in the hub client ID and its metadata header 300b. In some embodiments, the user client ID may simply comprise the PF field, TF field, and the unique ID field. [0073] In some embodiments, the user ID 210 changes at regular intervals. The frequency at which the user ID 210 may change is denoted as /V. Changing user IDs 210 at periodic intervals will assist with anonymity. The frequency N may be based on one or more factors, such as the computation time required to generate a new ID (calculating the new PF, etc.), and/or the number of IDs per person permitted while minimising the chance of duplicate IDs within the incubation period of the pandemic. The user device 112a, 112b may include memory that stores previous user IDs 210. The number of IDs that are stored locally on a device may be denoted as X. The number X may be used to generate a link between anonymous IDs and a single user. The number X may be based on one or more factors, such as the incubation period (/) of the pandemic in question, and/or the frequency in which the ID is changed. In some embodiments, X= N * I * f, where f is a buffer factor, e.g., 2, to ensure that the saved IDs are not truncated too early. In some embodiments, X and N may be determined and/or set, in part, based on a specific disease or pandemic.

[0074] The metadata header 220 may include at least one of i) a propagation factor (PF) field 222 for storing a propagation factor value that provides an indication of the risk of propagation; ii) a client type information field 224 that may include at least one of an individual identifier or name 232 associated with the client device, a business identifier or name 234 associated with a premises or location, and a geolocation identifier 236 for identifying a location; and iii) a client specific information field 226 that may include at least one of an age and/or age group value 242, a profession and/or profession category value 244, and a background propagation factor value 246.

[0075] In the event of a contact, the user ID 210 and its metadata are exchanged between client devices 112a, 112b. In some embodiments, part of the metadata may be kept private. For example some hubs could have restricted access to a user metadata, user-to-user contact may share a subset of the metadata, and/or user-to-hub contact may share a different subset of the metadata. Depending on the global seriousness of a pandemic, a third party (such a government agency) may impose that a larger (or smaller) set of the metadata may be shared at each contact.

[0076] FIG. 3C illustrates an example of user devices 112a, 112b exchanging propagation factors associated with the devices, in accordance with some embodiments. Client device 112a is showing client 112b’s propagation factor (PF) of 72% with a warning symbol. Client 112b is showing client 112a’s propagation factor (PF) of 14% with a safe symbol. A pre-calculated PF may facilitate offline contact (e.g., users meeting off the grid, and unable to poll a database for current results). Ultimately, the PF will be fully recalculated at regular intervals to ensure no data is missing from the calculation. In some embodiments, pre-calculating the PF may reduce the propagation factor calculation load at each point of contact. The PF will be reduced by a factor at each renewal interval. For example, if a day has passed since the last renewal and the client associated with the device has not shown any symptoms, then the likelihood that the client is infected will be lower and the PF will be decreased. The PF will be incremented by a factor dependent on its interactions during the most recent renewal interval. For example, if the client associated with the device comes into contact with a client that is at very high risk or infected, then the PF will increase accordingly.

[0077] Generally, the PF will be a function of the previous PF, contact log information and report log information. Contact log information may include at least one of contact type, duration and user type. Report log information may include at least one of interaction between users, positive/negative test results, degree of separation of a report (e.g., a user tested positive, or the user was in contact with someone who tested positive, or the user was in contact with a user who was in contact with someone who tested positive, etc.) Ultimately, each pandemic may have its own algorithm that may be determined by the epidemiologists and statisticians.

[0078] In some embodiments, the Propagation Factor (PF) is a value that characterizes the probability that a user is a carrier while the Transmission Factor (TF) is the weight factor an interaction that considers aspects such as ventilation, contact time, presence of PPE, and type of users. Some type of users could have their PF limited (e.g., if immunized with a vaccine with an efficiency of 15%, their PF could be limited to 15). Furthermore, some type of contact could also have the PF limited (e.g., if a user is only doing direct contact with low-risk user, their PF could be limited to a certain value).

[0079] As noted above, the updated value of a propagation factor can be expressed as a function of various factors. In some embodiments:

PF_i = f(PF_i-1 newContact, newReport, time)

[0080] The predictive function could be built from any kind of model (linear regression, logistic regression, regression tree, neural network, etc.). Such a model could have the form of a linear function. For example:

PF_i = β x PF_i-1 + ΔPF where p is the weight factor given to the current PF for the calculation of the next PF, and APF represents the change in propagation factor dependent on new contacts, new reports, and time:

where TFj is the weight of the contact, namely the transmission factor; M is the number of events (contact log, report log, time).

[0081] The transmission factor may depend on knowledge about the disease transmission and is a weight factor on the contact between two users. For example:

where a represents the factors of different aspects being considered. This includes some aspects that are more static (e.g., based on hub size, ventilation) and some that are more dynamic (e.g., density of users, activity, time of the day).

[0082] Overall, in some embodiments:

[0083] In some embodiments, the predictive function could be built from any kind of model (linear regression, logistic regression, regression tree, neural network, etc.). For example, it could also take the form of a logistic function such as:

Example of weight distribution for the transmission factor calculation

[0084] Table 1 illustrates an example of weight distribution for the transmission factor calculation.

Table 1 : Weight distribution for the transmission factor calculation

Example of PF decrease due to time

[0085] User A met with User B on t = 1. This interaction increased User A PF by 5 (ΔPF_t=1 = 5). After t = N+1 where N is the contact period (can be different for different type of user), this will be subtracted from the PF of User A (which is at 35 at t = N+1).

PF_{A,t=N +2} = PF_{A,t= N+ 1} — APF_t=1

PF_{A,t=N +2} = 35 — 5 = 30

[0086] In some embodiments, N could correspond to the incubation period (+ buffer) for an individual while it could correspond to the time that the disease particle can stay in a location for a hub.

Example of PF increase due to a new contact

[0087] User A (with a PF of 25) goes to Restaurant B (with a PF of 30). According to known information about the transmission of the disease, the maximal density of an installation should be 0.5 person/m² and a t_max of interaction of 3h is set.

[0088] For A:

PF_A,i = PF_A,i-1 + TF_A→B x PF_{B,i- 1}

• Restaurant B is an indoor installation with a new ventilation system (α₁ = 1)

• User A stays 2h in the restaurants

• There was no data for proximity for this type of interactions (α₃ = 1)

• User was only required to wear PPE when moving around the restaurant (and not at their table) (α₄ = 1)

• Based probability (α₅ = 0.5)

• The restaurant density is currently 0.6 person/m²

• User A is doing an activity where they do not move (α₇ = 0.5)

• User A is an individual (α₈ = 1)

[0089] As such, the transmission factor for A to B is: TF_A→B = (1)(0.66) (1)(1)(0.5)(1.32)(0.5)(1) = 0.2178 and the new PF of both A and B are updated after the interaction as:

PF_A,i = 25 + 0.2178 X 30 = 31.53

[0090] For B:

PF_B,i = PF_B,i-1 + TF_B→A x PF_{A,i -1}

[0091] Similarly, for the hub, this new contact will increase its PF.

• Restaurant B is an indoor installation with a new ventilation system (α_T = 1)

• User A stays 2h in the restaurants

• There was no data for proximity for this type of interactions (α₃ = 1)

• Based probability (α₅ = 0.5)

• The restaurant density is currently 0.6 person/m²

• User A is doing an activity where they do not move (α₇ = 0.5)

• User B is a hub (α₈ = 0.05)

[0092] As such, TF_B→A = (1)(0.66)(1)(1)(0.5)(1.32)(0.5)(0.05) = 0.01089 and the new PF is:

PF_A,i = 30 + 0.01089 X 25 = 30.27

Example of PF update following a contact with a confirmed case [0093] On t = 1, User A (with a PF of 29) interacted with User B (with a PF of 50). The transmission factor is calculated as TF_A→B = 0.135 and TF_B→A = 0.135:

PF_A,t=1 = PF_A,t=0 + TF_A→B x PF_{B t=0}

PF_A,t=1 = 29 + 0.135 x 50 = 35.75

[0094] Similarly:

PF_B,t=1 = PF_B,t=0 + TF_B→A x PF_At=0

PF_B,t=1 = 50 + 0.135 x 29 = 53.92

[0095] On t = 2, User A (with a PF of 36) meets User C (with a PF of 10). The transmission factor is calculated as TF_A→C = 0.135 and TF_C→A = 0.135:

PF_A,t=2 = 36 + 0.135 x 10 = 37.35

PF_C,t=2 = 10 + 0.135 X 36 = 14.86

[0096] On t = 5, User B tests positive and send a report to his contact of the last N numbers of days (where N corresponds to the contact tracing period) to let them know that they were in contact with a confirmed case (PF_B,t=5 = 100).

[0097] User A sees this report and get flagged as a first-generation contact. This increases the PF of the user to 80 from the initial contact with B.

PF_A,t=1 to 5 = 80

[0098] As a first-generation contact, User A transmits their new PF in a report log. User C is now flagged as a second-generation contact and must update their PF by going back to their logged interaction with User A:

PF_C,t=2 ⁼ PFc,_t=1 + TF_C→A X PF_A,t=2

PF_C,t=2 = 10 + 0.135 x 80 = 20.8

[0099] User C now has to update their current PF (at t = 5):

PF_C,t=5 ⁼ PF_C,t=2 + ΔPF_C,t=3 to 4 [0100] Transmission factors could also include aspect like immunity that would limit the PF of an individual based on the type of immunity. For example, acquired immunity would limit the PF of an individual to 0 until their system is not immune anymore. In the case of a vaccine, the PF could be limited to the vaccine efficacy. Actions, such as having contracted the disease or having taken a vaccine for the disease, may be tracked and/or otherwise taken into consideration when determining the PF for a user.

[0101] The multi-factor contact-confirmation function 250 may comprise technology to merge different sources of contact detection. For example, the multi-factor contact-confirmation function 250 may include at least one of a manual check-in/check-out function, a geolocation (GPS) function, Bluetooth™ connectivity, and a proximity function. The external sensor interfaces 270 may include at least one of a heart rate sensor interface, a body temperature sensor interface, and a sleep pattern sensor interface. In some embodiments, random or automatic personal protective equipment (PPE) validation may take place at designated check- ins. For example, facial recognition technology can be used to determine if the user is wearing a face mask, and this can be used to dampen the effect on their propagation factor (e.g., entering a hub with a face-mask might cause the user’s PF to increase 5 points instead of 10). The user can be prompted to submit a picture of them wearing a mask when they check in to certain locations. If declined, they would be assumed to not have a mask (i.e., worst-case scenario).

[0102] In some embodiments, a user who actively uses the application (with “good” habits) may have a lower PF and/or better score that an average user. Similarly, in some embodiments, a user who does not actively use the application (and/or otherwise shows “bad” habits) may have a higher PF and/or lower score than an average user. In some embodiments, such user compliance (and optional associated changes to PF and other scores) may be reflected in the user client ID header. When factors and IDs are updated/recalculated, a “compliance” factor may also be updated to let other users know how compliant the user is.

[0103] Tasks performed by the client application 300 include at least one of a) identifying and confirming contact (e.g., encounters) with other clients 112a, 112b, b) identifying and reporting a target client propagation factor, c) generating a contact entry and submitting it to the database 130, d) scanning the database 130 for new report entries to i) compare the list client IDs in the report block with the locally stored client IDs, ii) in the event of a match, use the associated metadata to determine the impact on the client propagation factor, and iii) update the client propagation factor accordingly, and e) client self-reporting, following the report process, including at least one of i) information provided by external sensors (automatic) and ii) information provided by the user (manual).

[0104] In some embodiments, the disease reporting input component 120 comprises at least one client 112b and a reporting unit 122 for reporting positive or negative test result data to a report log entry 124 of the database 130. The positive or negative test result data may include identifiers of other clients with whom the at least one client 112b has come in contact during a contact trace period. In some embodiments, if a person tests negative, their PF may be decreased by a certain factor, which would in turn cause a wave of PF reduction throughout their contacts in the same fashion as a PF increase would be sent: i.e., through reports.

[0105] In some embodiments a client may self-report via a client device 112a, 112b or other device, via a manual input or automatically via personal sensors. For example, a client’s temperature may rise to a level associated with a fever. The temperature sensor may sense this and report the temperature, date, time and optionally location.

[0106] In some embodiments, a reporter application is responsible for generating reports and for fishing for encounters related to a client to generate the reports. In some embodiments, a negative test may also be registered as a report. For example, a digital signature from certified testing stations (e.g., in the form of a unique code from the station) may be used to ensure no false reports are generated and submitted. The reporter application may be implemented on any device including other client devices, devices associated with businesses or locations, central disease monitoring entity devices, etc. Tasks performed by the reporter application may include at least one of a) searching the database for contact events regarding a specific collection of client IDs, b) determining the impact of each contact interaction based on the following criteria, non-inclusively: i) the duration of the contact; ii) the type of contact; iii) the severity of the contagion under investigation; iv) the client metadata information (e.g., age, profession, etc.), and c) building a report entry and submitting it to the database 130.

[0107] In some embodiments, the database 130 comprises either a central database or a decentralized database that includes at least one of a contact entry (e.g., contact log entry) and a report entry (e.g., report log entry). Contact log entries may include i) a metadata header that includes at least one of a contact type, a contact date, time, and duration, and a contact location, ii) a client 1 ID including its metadata header, and iii) a client 2 ID including its metadata header. Report log entries may include at least one of a report date, a list of clients that have been in contact with the reported individual, and a list of metadata associated to each client including at least the severity of the contact (i.e., propagation factor influence or risk factor).

[0108] In some embodiments, the data may be stored in decentralized database, such as a blockchain. FIG. 7 illustrates an example of a database 700, in accordance with some embodiments. In this example, that database file is in the form of a blockchain. Using a blockchain allows the stored data to comprise interactions (including anonymous contacts), and reports of positive cases and their contacts, as well as associated metadata.

[0109] FIGs. 8A and 8B illustrate, in component diagrams, examples of client-to-client contact options 800a, 800b, in accordance with some embodiments. In some embodiments, there may be contact between a non-electronic client (e.g., an ID card with a physical code imprinted) and an electronic client. This extension includes at least a secure regional database/server that includes at least one or more physical codes, all user IDs 210 associated with the physical code(s), and an application programming interface (API) allowing other clients to query the database 130 with a physical code in exchange for a valid user ID 210 to complete the contact registration. In some embodiments, a regional server may host the regional database and may also act as a computing source to calculate and update registered user's PF.

[0110] FIG. 9 illustrates, in a component diagram, an example of a data analysis process 900, in accordance with some embodiments. The nature of the public contact/report database lends itself to data analysis by third party sources and/or integrated analysis tools, permitting at least one of real-time data analysis of all anonymous contacts and/or real-time updating of cl ient/re porter applications propagation factor calculation filters.

[0111] FIG. 10A illustrates, in a flowchart, an example of a method of generating a contact entry log 1000a, in accordance with some embodiments. The method 1000 comprises confirming that a contact has been established 1002 between two client devices. The client devices then exchange 1004 PF values. The PF values are displayed 1006. If the user decides to proceed 1008, then a complete contact entry is generated 1010. Otherwise, 1008, a minimal contact entry is generated 1012. Other steps may be added to the method 1000, including storing the contact entry into the database 130.

[0112] FIG. 10B illustrates, in a flowchart, another example of a method of generating a contact entry log 1000b, in accordance with some embodiments. In this example, a block is added in which the PF is locally recalculated. Given the PF is pre-calculated and saved locally, it is desired to timestamp this and force a re-evaluation of the PF if it exceeds some threshold. [0113] FIG. 11 illustrates, in a flowchart, an example of a method of generating a report entry log 1100, in accordance with some embodiments. The method 1100 comprises identifying a positive case 1102a. Alternatively, a sensor triggers a potential positive case 1102b. Alternatively, a manual input of conditions is entered 1102c. If a positive case is identified, then all client IDs are queried 1104 from the user. Next 1104, 1102b, 1102c, the database 130 is scanned 1106 for all related contact entries. Next, the severity of a contact is evaluated 1108 from the entry metadata. Next, the report entry is generated 1110 with relevant client IDs and severity metadata. Other steps may be added to the method 1100, including storing the report entry into the database 130.

[0114] FIG. 12A illustrates, in a flowchart, an example of a method of updating a PF 1200a, in accordance with some embodiments. The method 1200 comprises scanning 1202 a database 130 for new reports. When a new report is found 1204, report client IDs are cross-referenced 1206 with a user log of client IDs. If a match is found 1208, then the PF is updated 1210. Otherwise, the PF is not updated 1212. Other steps may be added to the method 1200, including displaying a current or updated PF.

[0115] FIG. 12B illustrates, in a flowchart, another example of a method of updating a PF 1200b, in accordance with some embodiments. In this example, a report of Nth degree of separation between a positive case on the client is published, which can be used to propagate the reported case throughout the contact chain. In different embodiments, the degree to which this should propagate (i.e. , after how many people does it become unnecessary to publish, e.g., 5, 10, etc.) may vary. Many factors may influence this, including the disease characteristics and the computational effect this has on the solution as a whole.

[0116] FIG. 13 illustrates examples of client 1310, contact entry 1320 and report entry 1330 data structures, in accordance with some embodiments. The client data structure 1310 comprises a metadata header 1312 and an identifier 1314. The contact entry data structure 1320 comprises a metadata header 1322, a first client ID 1324 and a second client ID 1326. The report entry data structure 1330 comprises a plurality of client identifiers 1332 and their associated metadata 1334.

[0117] FIG. 14 illustrates an example of database interactions 1400 for different cycles, in accordance with some embodiments. In some embodiments, the regional database may store the previous codes of users who to not have portable electronic devices. I.e., the regional database may provide some anonymity for user without portable electronic devices such as mobile phones. In some embodiments, the public database may store all contact log entry information provided by user clients and hub clients, and disease information from clinics, hospitals and government or medical studies. In some embodiments, hubs may represent actual businesses, organizations, or groupings of individuals defined by specific geographical local locations. In some embodiments, hubs may represent a type or class of hubs, or a regional geographic area (e.g., city, province, state, country, etc.). Reports on such hubs may allow government or other bodies to make localized decisions or recommendations regarding the movement of users and/or the risk associated with certain types of establishments or gatherings and/or within different geographic areas.

[0118] In some embodiments, different locations in a geographic area may be deemed hubs that monitor when client devices 112a, 112b enter and/or exit the hubs. Users may be advised of the PF for a hub (an/or how entering the hub will affect the user’s PF) and can decide whether or not to enter. Time spent at a hub may be included in a contact log entry. If anyone associated with the hub, during the time period in which a client was at the hub, is found to be positive, then the client may receive a notification that they are at risk and their PF may increase accordingly. In some embodiments, hubs may be associated with an intensity of spreading metric (which could be denoted in the hub client metadata) that can be used when determining the risk and increase to the user’s PF that may occur if the user enters the hub. In some embodiments, a hub has use a user’s PF to determine whether or not to allow the user to enter the hub. In some embodiments, differences between a private client (e.g., user mobile device) and a hub client include: (1) Hub clients will contain information in their metadata regarding their propagation factor filters, i.e. , the effect checking in to a specific hub should have on a user’s propagation factor; (2) PF threshold filters, set by a third party (e.g., regional or governmental studies and policies), indicating the acceptable level of PF a user can have to check in at a hub; (3) Dynamic studies performed on hubs and report propagation, updating hub thresholds and PF application filters real-time.

[0119] FIGs. 15 and 15A to 15E illustrate, in a component diagram, another example of a contact tracing system 1500, in accordance with some embodiments. FIGs. 15A to 15E are exploded portions marked in FIG. 15.

[0120] FIG. 16 illustrates, in a component diagram, an example of a regional database/server 1600, in accordance with some embodiments. [0121] FIG. 17 is a schematic diagram of a computing device 1700 such as a server or other computer in a device such as a vehicle. As depicted, the computing device includes at least one processor 1702, memory 1704, at least one I/O interface 1706, and at least one network interface 1708.

[0122] Processor 1702 may be an Intel or AMD x86 or x64, PowerPC, ARM processor, or the like. Memory 1704 may include a suitable combination of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM).

[0123] Each I/O interface 1706 enables computing device 1700 to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, or with one or more output devices such as a display screen and a speaker.

[0124] Each network interface 1708 enables computing device 1700 to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, and others.

[0125] The discussion provides example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus, if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.

[0126] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface (which in some embodiments includes the use of a QR code, an NFC signal, or other communication technology). [0127] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.

[0128] Throughout the foregoing discussion, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

[0129] The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments.

[0130] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements.

[0131] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein.

[0132] Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification.

[0133] As can be understood, the examples described above and illustrated are intended to be exemplary only.

Claims

WHAT IS CLAIMED IS:

1. A system for contact tracing a user device, the system comprising: at least one processor; and a memory comprising instructions which, when executed by the processor, configure the processor to: send a user propagation factor value to a hub device; and receive access notification to the hub based on the user propagation factor value and a threshold value.

2. The system as claimed in claim 1 , wherein access to the hub is permitted when the user propagation factor value is less than a threshold.

3. The system as claimed in claim 1 , wherein access to the hub is denied when the user propagation factor value is greater than a threshold.

4. The system as claimed in claim 1 , wherein the threshold value is based on an intensity of spreading value associated with the hub.

5. The system as claimed in claim 1, wherein the at least one processor is configured to record at least one of: a time of entry to the hub associated with the user device; a time of exit from the hub associated with the user device; or a user client identifier associated with the user device.

6. The system as claimed in claim 5, wherein the at least one processor is configured to send to a public database at least one of: the time of entry; time of exit; or the user client identifier.

7. The system as claimed in claim 1, wherein the at least one processor is configured to: receive a hub propagation factor value to the user device; and display a hub entry suggestion based on the hub propagation factor value.

8. The system as claimed in claim 1, wherein the at least one processor is configured to generate a user client identifier anonymously associated with the user device, the user client identifier associated with the user propagation factor value.

9. The system as claimed in claim 8, wherein the at least one processor is configured to: periodically generate a new user client identifier associated with the user device; and store at least one previous user client identifiers in a memory.

10. The system as claimed in claim 8, wherein the at least one processor is configured to: obtain report details from a database, the report details including at least one of: an updated hub propagation factor value for each hub in which the user device has frequented over an incubation period; and an indication if any other user client identifier present at any such hub, when the user device was present at that hub, has tested positive; and determine an updated user propagation factor value based on the obtained report details.

11. A method for contact tracing a user device, the method comprising: sending a user propagation factor value to a hub device; and receiving access notification to the hub based on the user propagation factor value and a threshold value.

12. The method as claimed in claim 11, wherein access to the hub is permitted when the user propagation factor value is less than a threshold.

13. The method as claimed in claim 11, wherein access to the hub is denied when the user propagation factor value is greater than a threshold.

14. The method as claimed in claim 11 , wherein the threshold value is based on an intensity of spreading value associated with the hub.

15. The method as claimed in claim 11, comprising recording at least one of: a time of entry to the hub associated with the user device; a time of exit from the hub associated with the user device; or a user client identifier associated with the user device.

16. The method as claimed in claim 15, comprising sending to a public database at least one of: the time of entry; time of exit; or the user client identifier.

17. The method as claimed in claim 11, comprising: receiving a hub propagation factor value to the user device; and displaying a hub entry suggestion based on the hub propagation factor value.

18. The method as claimed in claim 11 , comprising generating a user client identifier anonymously associated with the user device, the user client identifier associated with the user propagation factor value.

19. The method as claimed in claim 18, comprising: periodically generating a new user client identifier associated with the user device; and storing at least one previous user client identifiers in a memory.

20. The method as claimed in claim 18, comprising: obtaining report details from a database, the report details including at least one of: an updated hub propagation factor value for each hub in which the user device has frequented over an incubation period; and an indication if any other user client identifier present at any such hub, when the user device was present at that hub, has tested positive; and determining an updated user propagation factor value based on the obtained report details.

21. A system for contact tracing at a hub, the system comprising: at least one processor; and a memory comprising instructions which, when executed by the processor, configure the processor to: receive a user propagation factor value from a user device; and determine access to the hub based on the user propagation factor value and a threshold value.

22. The system as claimed in claim 21, wherein the at least one processor is configured to permit access to the hub when the user propagation factor value is less than a threshold.

23. The system as claimed in claim 21, wherein the at least one processor is configured to deny access to the hub when the user propagation factor value is greater than a threshold.

24. The system as claimed in claim 21, wherein the at least one processor is configured to determine the threshold value based on an intensity of spreading value associated with the hub.

25. The system as claimed in claim 21, wherein the at least one processor is configured to record at least one of: a time of entry to the hub associated with the user device; a time of exit from the hub associated with the user device; or a user client identifier associated with the user device.

26. The system as claimed in claim 25, wherein the at least one processor is configured to send to a public database at least one of: the time of entry; time of exit; or the user client identifier.

27. The system as claimed in claim 21, wherein the at least one processor is configured to provide a hub propagation factor value to the user device.

28. A method of contact tracing, the method comprising: receiving a user propagation factor value from a user device; and determining access to the hub based on the user propagation factor value and a threshold value.

29. The method as claimed in claim 28, comprising permitting access to the hub when the user propagation factor value is less than a threshold.

30. The method as claimed in claim 28, comprising denying access to the hub when the user propagation factor value is greater than a threshold.

31. The method as claimed in claim 28, comprising determining the threshold value based on an intensity of spreading value associated with the hub.

32. The method as claimed in claim 28, comprising recording at least one of: a time of entry to the hub associated with the user device; a time of exit from the hub associated with the user device; or a user client identifier associated with the user device.

33. The method as claimed in claim 32, comprising sending to a public database at least one of: the time of entry; time of exit; or the user client identifier.

34. The method as claimed in claim 28, comprising providing a hub propagation factor value to the user device.