Patent Application
20220319311
This application is a U.S. National Phase application under 35 U.S.C. § 371 of International Application No. PCT/EP2019/071982, filed on Aug. 15, 2019, and claims benefit to European Patent Application No. EP 19178984.1, filed on Jun. 7, 2019. The International Application was published in English on Dec. 10, 2020, as WO 2020/244787 A1 under PCT Article 21(2).
The project leading to this application has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 825012.
The present invention relates to road safety, and more particularly, to a method for dynamic event-related information dissemination as well as to a road vehicle onboard system. The invention not only applies to vehicles, but also is applicable to any other observation entities in the form of mobile devices that have required sensing, computing and communication capabilities.
Events like accidents and road-works (or civil works in areas adjoining the roads) may result in traffic congestion causing unexpected delays for the commuters. The duration of such congestions at choke-points may range from a few minutes to hours, days, weeks or months depending on the type of event. For instance, minor accidents may result in road congestion lasting for 10s of minutes while serious accidents may result in congestion that may last for several hours. Similarly, events like regular road maintenance may last for a few days while major construction projects may cause congestion lasting for weeks and months.
Existing automotive systems do not have efficient provisions to warn and/or divert a vehicle away from temporary choke-points on the roads except for radio announcements and relay of vague traffic congestion warning via the navigation system asking the drivers to choose for an alternate route without specifying any reason nor details. Such information is usually untimely and may also be stale by the time when the message is received, and in addition does not include information specifying the reason and the impact the events caused.
With reference to the state-of-art analysis, almost all the methods/systems for vehicular situation awareness rely at some level on the availability of external sensors and soft information systems in addition to limited vehicular objects. Example of external sensors are road-side cameras (with fixed perspective), flow measuring devices, automatic traffic jam detectors, etc., whereas examples of soft information sources are call centers (where drivers call in to inform of prevailing road/traffic conditions), FM radio stations, weather stations, public event information system, traffic management system, road-works information system, etc. Most soft information systems have a “human-factor” that impacts the reliability of developing an accurate event identification and the accuracy of the information, and that incurs delays in disseminating the information. Furthermore, call center solutions are insecure as the drivers report the event via phone, which is illegal and dangerous.
In an embodiment, the present disclosure provides a method for real-time and dynamic event-related information derivation and dissemination by a road infrastructure to control, coordinate and consolidate information from one or more observation entities. The method includes receiving, by a road infrastructure server of the road infrastructure, event information from the one or more observation entities. Each of the one or more observation entities provides its event information as an event information frame that comprises an event data record including a number of attributes together with a unique identifier referencing the event data record. The event information frames received from the one or more observation entities are collected and analyzed, and are processed to generate a combined event information frame that includes composite event information, a unique identifier referencing the composite event information, and control commands to coordinate communication with the one or more observation entities. The combined event information frame is distributed within a distribution domain.
Subject matter of the present disclosure will be described in even greater detail below based on the exemplary figures. All features described and/or illustrated herein can be used alone or combined in different combinations. The features and advantages of various embodiments will become apparent by reading the following detailed description with reference to the attached drawings, which illustrate the following:
Embodiments of the present invention improve and further develop a method for dynamic event-related information dissemination as well as a road vehicle onboard system in such a way that an efficient, fine-granular and effective issuance of in-advance warnings in near real-time to vehicles on road choke-points that may exist on a planned route is enabled.
In accordance with an embodiment of the invention, the enablement of efficient, fine-granular and effective issuance of in-advance warnings in near real-time to vehicles on road choke-points that may exist on a planned route is accomplished by a method for real-time and dynamic event-related information derivation and dissemination by a road infrastructure to control, coordinate and consolidate information from at least one observation entity, the observation entity being preferably an independent vehicle, a mobile device or the like, the method comprising:
receiving, by a road infrastructure server of the road infrastructure, event information from one or multiple observation entities, wherein each of the observation entities provides its event information as an event information frame that comprises an event data record including a number of attributes together with a unique identifier referencing the event data record,
collecting and analyzing the event information frames received from the observation entities and processing them to generate a combined event information frame that includes composite event information, a unique identifier referencing the composite event information, and control commands to coordinate the communication with the observation entities, and
distributing the combined event information frame within a distribution domain.
In another embodiment of the invention, the enablement of efficient, fine-granular and effective issuance of in-advance warnings in near real-time to vehicles on road choke-points that may exist on a planned route is accomplished by a road vehicle onboard system, comprising an onboard unit, OBU, that provides computational and communication capabilities and that is configured:
to receive event-related raw sensor data from a vehicle's onboard sensor system and/or from a smart device carried along by the vehicle's driver,
to process the received raw sensor data and to generate an event-data record that contains attributes in form of contextual event-descriptive information derived from the raw sensor data,
to generate, based on the attributes of the event-data record, a unique identifier referred to as event_signature,
to create an event information frame that contains at least the event_signature and the attributes of the event-data record, and
to transmit the event information frame towards a road infrastructure server.
Embodiments of the present invention provide an efficient method and system for dynamic event identification, dissemination and update. Embodiments of the invention enable a context-based identification and evaluation of road events and a fast and autonomous dissemination of such events by moving objects (e.g., vehicles) in a cooperative way that is centrally coordinated by infrastructure servers.
In contrast to prior solutions, the method and system according to embodiments of the invention are independent of reliance on any external sensors and/or soft information systems (i.e., infrastructure-less) and basically rely on leveraging the on-board sensor cluster available on the target object (i.e., vehicle), and can also include the smartphone carried by the driver/passengers as it offers its own ecosystem of sensors. Embodiments of the invention also rely on the all-pervasive mobile network infrastructure to accurately identify and determine the event and disseminate it in near-real time. Thus, the scope of embodiments of the invention also applies to any road network and not just highways. The main dependence is on the availability of a mobile network infrastructure. Moreover, embodiments of the invention factor out any human intervention (zero touch), thus allowing more precise, consistent and fine granular event identification and dissemination (to other vehicles or to first responders in case of accidents) by leveraging on information generated by independent mobile objects (i.e., vehicles). As such, embodiments of the invention are also suited to autonomous (self-driving) cars.
In contrast, prior art approaches appear to not have a central coordination of collecting the information from multiple vehicles on the road. They send their context information to the infrastructure server independently and periodically. However, this causes the problem of periodically sending duplicated information reporting the same event by the same car as well as by multiple cars in the area, which wastes the network resources (especially on uplink) unnecessarily which may result in network congestion and overload, while incurring high processing load and long delays for other mobile data communications.
Embodiments of the present invention leverage on the vehicles' on-board sensors and computational capabilities (on-board compute resources) to derive a unique identifier (event-signature) for the event and explore the V2X communications in collaboration with the road infrastructure servers to identify and analyze the event and its severity, and disseminate this information in a variety of ways, such as notifications to first-responders in near-real-time and/or dynamic update of navigation maps and route plans to a specific range of area where the events causing choke points on the road. The challenge is to enable the timely and accurate acquisition of event information and its dissemination to vehicles in a cost effective manner consuming minimum processing and radio resources.
According to embodiments, the present invention relates to a method at an infrastructure server to control, coordinate and consolidate the information from one or multiple independent vehicles or other observation entities. This may include identification and clustering of event information from multiple sources, i.e. vehicles, and generating a combined event identifier along with a set of selected attributes and control flags to command the vehicles to send relevant updated information if necessary. Moreover, this may include consolidating the collected event information from multiple independent vehicles for joint analysis to provide a high granular and more complete and accurate information updates.
According to embodiments, the vehicles and/or other observation entities may provide/notify information regarding their observation/recording of an event in the form of an event information frame. The road infrastructure servers may collect and analyze the event information frames received from vehicles and/or other observation entities and process them to generate a composite information snapshot that may be encoded in a special frame (i.e., the combined event information frame). The distribution of the combined event information frame within a distribution domain may be realized via broadcast, multicast, anycast or unicast transmissions. The size of the distribution domain may be determined by the overall impact that can be derived from an event impact factor and/or delay factor of the respective event.
According to embodiments, the unique identifier included in the event information frame may be an event_signature derived from selected attributes of the event data record, such as by applying a hash algorithm. Alternatively, the identifier may be an unambiguous number derived from the respective vehicle, e.g. including a sequence number and a vehicle identifier, etc. Similarly, the unique identifier included in the combined event information frame may be a combined event_signature derived from the composite event information, such as by applying a hash algorithm.
According to embodiments, the present invention relates to a car onboard system, such as an OBU with sensors like camera, light, accelerator, etc., a processor, memories, and networking interfaces. The onboard system may include an image recognition application that may be used to identify an event, road signs and also decipher any textual information that may be stated on the road sign. The infrastructure computation enables to harmonize the event information from OBUs from different manufacturers with different image/text recognition application.
According to embodiments, a method may be performed inside the vehicles that identifies and processes (including filtering, classification and/or analysis) the raw data collected from on-board sensors (like cameras, GPS, speed, communication modules, radar, LIDAR etc.), to derive a local unique event identifier with a set of sensible event-data (e.g. event type, impact_factor, estimated event duration, delay_factor, etc.) including images/video data. The vehicles may be configured to send this information—contained within an event information frame—to an infrastructure server.
According to embodiments, the vehicles may be further configured to decode a “combined-event-information-frame” sent from the infrastructure server to identify the relevance of the indicated events to the vehicle and to execute requested actions. The respective actions may be indicated by the infrastructure server within the “combined-event-information-frame” by setting or activating respective control flags. For instance, a “SEND_MORE” flag may request the vehicle to send more event-related information to the infrastructure server, and a “UPDATE” flag may notify the vehicle that the “combined-event-information-frame” contains updated information.
According to embodiments, the infrastructure servers may include one or more MEC servers and/or a core server. Specifically, the infrastructure servers may be configured to perform a mechanism for duplicate event detection processing to identify the cluster of vehicles reporting the same event situation, as well as for combining the event information of this cluster of vehicles, e.g. by applying a convolution function. Additionally, the infrastructure servers may be configured to evaluate the attributes and/or the images (if applied) based on the input from this cluster of vehicles to determine the accuracy of the event information.
Embodiments of the invention aim to prevent vehicles to send duplicated information unnecessarily with the information coordination and identification by the infrastructure server, and without relying on external static information systems. Besides, the context information sent by multiple independent vehicles can be jointly analyzed (e.g. with graph AI or ML techniques, or signal/image processing) at the infrastructure server to provide a high granular and more complete information, which is then disseminated to relevant vehicles and/or stakeholders (e.g. emergency responders).
According to embodiments, as part of an information coordination task, the infrastructure server may be configured to command the vehicles to send more related information, if needed, to develop more accurate event information. By preventing sending duplicate information results in savings of network resources (especially on uplink), which may otherwise result in network congestion and overload thereby causing delay on disseminating event information, as well in reducing superfluous processing load on the backend servers processing the information which is sent upstream from vehicles.
Embodiments of the present invention leverage on the onboard sensors in a vehicle, such as the camera(s), GPS, monitor, communication modules, radar, LIDAR, etc., on the one hand and on a mobile network infrastructure on the other hand. The mobile network infrastructure may be controlled, coordinated and managed by one or more infrastructure servers (e.g., multi-access edge computing, MEC, servers) to enable quick, low-cost, dynamic and accurate event identification and dissemination to road users, i.e. vehicles, and to other stakeholders (e.g., emergency responders) to warn about events and event locations providing real-time event information with pin-point accuracy. The event locations are points on the route that may cause traffic delays and can be characterized by events such as congestion, road-works, accidents, etc. Recipients receiving such warning can then exploit the received information in different ways, e.g., by recalculating routes enabling the vehicles to circumnavigate the event locations (e.g., choke points). The process is enabled with a minimum consumption of compute and radio resources while still remaining scalable.
A RSU 2 is a communication device, such as Radio Base Station, that is used for communicating information with observation entities 10, i.e. in particular with the vehicles 1, but also with mobile devices or the like. To this end, RSUs 2 are deployed along the roadside. For example, a RSU 2 can be installed at a traffic light or at a cellular radio base station.
The edge-servers (ES) 3 are computing platforms that are located either at a central location, such as an edge cloud datacenter 5, or they may be distributed and collocated with the RSUs 2, e.g. at traffic lights, etc. According to an embodiment of the edge-servers 3 may be implemented in form of MEC (multi-access edge computing) servers in an edge cloud infrastructure. The core servers (CS) 4 may be implemented in a core data center 6.
According to the embodiment illustrated in connection with the scenario of
Specifically,
According to some embodiments event data processing by a vehicle 1 may be triggered when the vehicle 1 detects an event based on the processing of the output of the vehicle's 1 onboard sensors, e.g. camera images that the vehicle 1 has captured of the event. The vehicle's 1 onboard sensor system may be triggered to take images and send them for processing to the on-board unit (OBU), as depicted in step S201 of
According to the exemplary functional overview in
The output of the ERE 7, as provided in step S203, is an Event-data record that contains processed contextual data derived from the raw-data as part of the ERE 7 processing. For instance, from the images received from the vehicle's 1 on-board cameras, the image/text recognition and processing application 701, which is part of the ERE 7, may identify event related information, e.g. by deciphering any textual information that may be stated on road signs to create a more clear event context. Based on the evaluated event context, the ERE 7 may specify the type of the event (which may be recorded as event_type). Moreover, relevant temporal information received from the various sensors of the vehicle 1 can be jointly processed to derive information on a potential impact of the identified event. For instance, this information may be recorded as an event impact factor.
Table 1 below provides an example embodiment of an Event-data record with a non-exhaustive list of event-data together with the respective definition.
According to embodiments the ERE 7, based on the Event-data record, creates a unique event_signature that is construed as a unique identifier referencing the event-data record. The event_signature can be derived from the Event-data record by one of several well-known methods, such as hash algorithms. According to embodiments, the granularity of Event-data specified in Table 1 above, like for instance event_geo_location and speed range, is kept coarse (i.e., above a configurable granularity threshold) in order ensure the ERE 7 to be generating the same event_signature independent of slight changes (i.e., below the granularity threshold) in distance and/or speed.
The ERE 7, after having created the event_signature, will create an “event_Information_frame”, as shown in step S204 of
The process starts at S301 by first initializing two counters N and M, by setting N:=0 and by setting M:=0, as shown at S302. At S303, the vehicle's 1 OBU receives raw sensor data (such as camera images and/or videos, GPS coordinates, speed and direction information, etc.) collected by the vehicle's 1 on-board sensor system. Basically, this step corresponds to step S201 of
Next, at S304, dedicated applications of the ERE 7 perform image recognition and processing of the sensor data, as well as data filtering and classification. Basically, this step corresponds to step S202 of
At S305, the ERE 7, based on the outcome of the data analysis performed in the previous step, generates an event-data (corresponding to step S203 of
According to the illustrated embodiment the process defines two threshold, namely T and T′, such that T>T′. The threshold T′ is intended to govern the number of sampling rounds to collect and sample data from on-board sensors. On the other hand, this threshold T is intended to govern the number of times the process is repeated to ensure the uniqueness of the derived event_signature.
More specifically, as shown at S307, the ERE 7 will sample and process raw data T′ number of times to derive event_signature and ensure that it is unique. In case the event_signature uniqueness test (as performed at S308) fails, then the same process will be repeated T times (S309). After a unique event_signature has been derived from the Event-data record, an event-information-frame will be generated as described above with reference to
It should be noted that the sampling rate of the on-board sensor data may also be controlled by the infrastructure in case the ES 3 requires the vehicle 1 to send more samples of event-data in order to create a high granular perspective of the event, as will be explained later.
With reference to
As shown at step S402, the infrastructure server may then jointly process the information received within the event-information-frames from vehicles 1 labeled ‘A’ and ‘B’ to create a high quality/granular event perspective. As part of this process, the infrastructure server may combine the event_signature from multiple event-information-frames to derive a combined event_signature (denoted combined_event_signature). The combining may be performed by using some coding technique or by convolution of the multiple event-signatures. For example, with reference to
According to an embodiment, the combined_event_signature (S) may be embedded in a Combined-Event-Information-Frame along with control_flags, such as a SEND_MORE flag and/or an UPDATE flag, as well as the attributes from the constituent event-information-frames. Optionally, the image/video information, the warning message, and/or the map update information can also be embedded in the Combined-Event-Information-frame. A generic format of a Combined-Event-Information-Frame according to an embodiment of the invention is shown in
As shown at step S403, after having processed the event-information from multiple sources as described above, the infrastructure server will broadcast the generated Combined-Event-Information-Frame with updated information. A decoder inside the vehicle's 1 OBUs will decode the combined-event-signature (S) to extract the constituent event_signatures (i.e., S1 and S2 in the described scenario) and store the updated information elements along with the individual event_signatures in an internal Event-database (EDB) which will be mapped to the combined-event-signature. This database may then be used by subsequent vehicles 1 approaching the event location to decide whether or not to send information to the infrastructure, as will be described later. An example embodiment of the EDB after it has been updated by the Combined_Event_Information-Frame is shown in Table 2 below. Since it is based on broadcasted information, all the vehicles 1 receiving the Combined_Event_Information_Frame will have the same entries.
As shown in
There are many indications in the EDB that vehicle ‘D’ can use to determine if the event has been previously reported or if it is a new event. For instance, according to an embodiment it can compare its own event_signature internally derived for the event with those already stored in its EDB. In case vehicle ‘D’ derives Si as an event_signature, then it will know that the event has already been reported and processed, as indicated by S, and that it has an updated Event Data Record. In that case, vehicle ‘D’ will stop the process and will not report it to the infrastructure server. Alternatively or additionally, the geo location information in the Updated Event Data Record will enable vehicle ‘D’ to decide whether to trigger the event identification process or not.
According to embodiments, the same process can be used to report when an event has been resolved, which can then be broadcasted to vehicles 1 to clear the particular Event Data Record from their respective EDB. This method will therefore reduce the duplication of event reports and on-air traffic load, thus reducing consumption of infrastructure including computing, networking and radio resources.
Moreover, the impact_factor and the delay_factor (as specified in Table 1 above) that is derived by the infrastructure server can also enable the infrastructure server to determine the size of the braodcast domain. For instance, in case of events with high impact_factor and with high delay_factor (i.e. above configurable thresholds), the infrastructure server may be configured to broadcast such an event information to a wider geographical area.
With reference to the process summary described above,
Next, as shown at 5502, the RSU 2 processes this data locally, or send it to a remote processing sever e.g., ES 3 to (re-)analyze the event_signature based on the event_data derived by the reporting vehicle 1. More specifically, the RSU 2 or ES 3 may be configured to validate and analyze the data and/or images received from multiple vehicles 1 in the area for the same event. For instance, at a crossing there may be several cars taking images of the crossing from different angles. According to some embodiments, graph AI techniques may be applied to analyze the images so as to (1) identify whether the event information is duplicate or still up-to-date, and (2) to process multiple images jointly to provide more accurate information of the event. A decision of whether more information is required from the vehicles 1 is made at S503.
If the ES 3 (or CS 4) requires more information from the vehicles 1, e.g. in order to create a more accurate identification of an event, it will broadcast the Combined-Event-Information-Frame with the control flag SEND_MORE flag set to TRUE, as shown at S504. The vehicles 1 recognizing the message will send more information following the process explained above with reference to
At S505, the processing infrastructure servers, i.e. either the ES 3 or CS 4, broadcast the final Combined-Event-Information-Frame via the RSUs 2 with the updated information. In case the Combined-Event-Information-Frame contains updated information from that received in the Event-Information-Frame, a control flag within the Combined-Event-Information-Frame referred to as UPDATE flag may be set to TRUE.
According to embodiments the Combined-Event-Information-Frame may also optionally carry updated images of the event, e.g., a 3D-image of the event formed after combining images from different reporting vehicles 1. It may also optionally carry suitable warning signals and/or map updates appropriate to the type of event. For instance, suitable warnings may be derived by the infrastructure servers depending on the event_impact_factor, delay_factor, estimated_event_duration, estimated_delay and traffic_state (as defined in the above Table 1). Based on the received information a vehicle's 1 local navigation system may recalculate the route. According to embodiments, the respective processing server may also suggest a new route plan to bypass/avoid the event. As a result, these embodiments enable a dynamic update of maps and/or route plans with reduced uplink traffic thereby saving on radio resources and compute resources at the infrastructure servers.
Depending on the relevance and/or severity of the event, it may be provided that the processing server, in case of events with a high impact_factor and delay_factor, i.e., above configurable thresholds, relay the map updates to a central server, e.g. CS 4. This will enable the central server to make map updates and push them towards all RSUs 2. The map updates when broadcasted may also include the event_signature that is stored in the EDB of the receiving vehicles 1. This is done to ensure against unnecessary reporting of events that have already been reported by earlier vehicles 1, as described above.
Finally, as shown at step S506, upon reception of the Combined-Event-Information-Frame by a vehicle 1, the OBU will decode the “Combined-Event-Signature” to map to the local event-data, and to update the relevant information in the vehicle's 1 EDB, as described above.
It should be noted that the processing of vehicular information within the infrastructure is done either at the RSUs 2, provided they have the processing capabilities, or it is relayed to an ES 3 inside the edge datacenter 5. The ES 3 will then relay the processed information (i.e., the event_signature) to the vehicles 1 via the RSUs 2 that are associated to it. The decision to further relay this information to the CS 4 inside the core datacenter 6 may be taken depending on the level of permanence determined from the values of the parameters event_impact_factor, delay_factor, estimated_event_duration. For example, high impact events of long duration may be relayed to the CS 4 so that the map updates can be broadcasted to vehicles 1 in a much larger region for future route calculations. In other words, the derivation of the event impact factor allows for the decision on the scope of dissemination of map updates.
After the maps are updated with choke-points pinned on the maps, then the next time when a vehicle 1 approaches any of the choke points, a trigger will be sent to the vehicle's 1 OBU to solicit the sensors for information. In case the event has been resolved and the traffic flow is normal, then a different event_signature (e.g. a different hash) will be computed than the previous one with an indication of the resolution of the previously reported event. This may then be sent to and processed by the ES/CS 3, 4 in a similar manner as depicted in
According to embodiments, along with the downstream notification (i.e. infrastructure to vehicles 1) of an event_signature and the attributes/values, which comprise event-descriptive information per the associated event data record, the infrastructure nodes (i.e. ES 3, CS 4) may be configured to provide additional control information to the vehicles 1. This control information may determine on the one hand how vehicles 1 should treat continuously or additionally captured information associated with a known event (i.e., whether or not to send such information upstream to the infrastructure), as well as how to treat distributed information sent downstream from the infrastructure to the vehicles 1.
Regarding control information associated with the treatment of captured information at vehicles1, it may be provided that the infrastructure servers are capable of requesting a vehicle 1 to continue sending additional data associated with a known event (i.e. the vehicle 1 has an entry of the event_signature already in its event_signature database) upstream towards the infrastructure. This mechanism enables the infrastructure to build a more accurate description of the event and situation. For example, additional camera pictures from different vehicles 1 taken from different angles allow the infrastructure creating a 3D- or rotating image of the situation. In this context it may be provided that the event is visualized from the perspective of a particular vehicle 1 according to its direction from which it approaches the location associated with the event. Also, multiple samples of a delay factor from multiple vehicles 1 allow the infrastructure to build a more accurate average or updated value, or to build a delay factor in dependency of the direction from which a vehicle 1 approaches the location associated with the event. A request for such control information may be indicated by the control tag “SEND_MORE” in the message Combined-Event-Information-Frame sent from the infrastructure nodes (ES 3, CS 4) to the vehicles 1.
Regarding control information associated with the processing of received downstream information from the infrastructure, it may be provided that the infrastructure indicates to the vehicles 1 to not only lookup and match the event_signature with entries in its local event_signature_database, but to process the attached attributes/values. The reason for this may be that, e.g., updated information is included, for example a more accurate event situation description, changes in the described situation, etc. Such control information may be indicated by the control tag “UPDATE” in the message Combined-Event-Information-Frame sent from the infrastructure nodes (ES 3, CS 4) to the vehicles 1.
Many modifications and other embodiments of the invention set forth herein will come to mind to the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
While subject matter of the present disclosure has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. Any statement made herein characterizing the invention is also to be considered illustrative or exemplary and not restrictive as the invention is defined by the claims. It will be understood that changes and modifications may be made, by those of ordinary skill in the art, within the scope of the following claims, which may include any combination of features from different embodiments described above.
The terms used in the claims should be construed to have the broadest reasonable interpretation consistent with the foregoing description. For example, the use of the article “a” or “the” in introducing an element should not be interpreted as being exclusive of a plurality of elements. Likewise, the recitation of “or” should be interpreted as being inclusive, such that the recitation of “A or B” is not exclusive of “A and B,” unless it is clear from the context or the foregoing description that only one of A and B is intended. Further, the recitation of “at least one of A, B and C” should be interpreted as one or more of a group of elements consisting of A, B and C, and should not be interpreted as requiring at least one of each of the listed elements A, B and C, regardless of whether A, B and C are related as categories or otherwise. Moreover, the recitation of “A, B and/or C” or “at least one of A, B or C” should be interpreted as including any singular entity from the listed elements, e.g., A, any subset from the listed elements, e.g., A and B, or the entire list of elements A, B and C.
| Number | Date | Country | Kind |
|---|---|---|---|
| 19178984.1 | Jun 2019 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2019/071982 | 8/15/2019 | WO |
