IL303141A - A method for multi-party policy for communication devices - Google Patents

Description

METHOD FOR TELECOMMUNICATIONS DEVICES MULTIUSER POLICIES Field of the invention The invention object of this application relates to the reduction of different types of hazards connected to the use of cellular phones by using a method implemented in an array of telecommunication devices.

Background of the invention The use of cellular phones entails a number of hazards such as loss of concentration while driving, exposure to EM radiation and so forth.

These problems and proposed solutions are the subject matter of patents IL1862and 189482 by the same applicant of this application.

IL186275 and 189482 are hereby incorporated by reference.

Since some of the terms and the premises of said patents are mentioned in this application, it may be useful to mention briefly some of the relevant passages in IL186275 and 189482 as a background of the present application.

The meaning of the same terms in IL186275, Il 189482 and in the present application are equal unless stated differently.

IL1862 “It is purpose of this invention to provide a solution that reduces dramatically the hazard involved in the use of TCD”. (pg. 2) “By "telecommunication device" or in short "TCD", we mean wireless telecommunication devices, in particular cellular phones, PDA, Smartphones and other handheld devices”. (pg. 3) “The user that influences how another user will be using the TCD is called the "Authorized User"” (pg. 3).

“The user who has no control or authority over the phone will be called the "Subordinate User"” (pg. 3).

“The term "sound input and/or output channels" in this application applies to any element, hardware and/or software, that enables the user to speak and to listen to the other party in the course of a conversation. (pg. 5) The sound input and/or output channels may be built in elements of the TCD or external and/or add-on devices and accessories coupled in any way with the TCD. The most obvious examples of sound input and/or output channels include: earphone loudspeaker, built-in speakerphone, any additional loudspeaker, built-in microphone, headsets of any kind (Bluetooth, infrared, plugged in etc.) comprising earphone loudspeaker and/or microphone and handsfree-car kit. The most common types of sound input and/or output channels are additionally described in Figure 2 and in its description (pg. 6).

By the term "policy" it is meant the collection of the statuses ("enabled" or "disabled") of all the different sound input and/or output channels as determined by the Authorized User (pg. 9).

IL 189482 Background of the Invention and Prior Art “The above mentioned inventions do no provide the means to motivate the user to position the telephone within safe range in order to reduce hazards connected to use of wireless telecommunication devices such as exposure to electromagetic radiation of the body and/or the head, exposure to electromagetic radiation of a pregnant woman, a fetus,or a child, loss of concentration while driving, interference with pacemakers or similar instruments” (pg. 2).

“A solution to this problem is described in this application. The invention relates to a novel headphone which, in addition to the functionalities of conventional headsets is capable of estimating the distance of the TCD from any part of the body and the head. This novel headphone is capable of responding to situations where the TCD is to close to the body or the head by generating commands the warn the user of the dangerous situation and motivate him/her to rectify the dangerous situation by positioning the TCD within safe range” (pg. 3).

“Some non-limitative examples of said reaction/s by the TCD (1) to warning commands issued by the headset (2) and execute by the Policy Program could include, for example one or more of the following: a - causing a text message or a graphic content to appear to the TCD (1) screen (28). b - causing the TCD (1) to vibrate. c - causing the TCD (1) to terminate the current communication d - causing the TCD (1) to emit a predetermined sound. e — any combination of two or more of the above a-e possibilities” (pg. 16).

It should be noted that both IL 186275 and IL 189482 relate to the reduction of hazards connected to a single cellular phone configuration.

Bearing in mind what mentioned above, it is a purpose of this invention to provide a method by which a number of cellular phones that are related andor function as an array of telecommunication devices, provide a solution to a variety of cell phone-related hazard.

It is another purpose of this invention to enable a configuration whereby said array of telecommunication devices consists of, at least, a Leading Device which influences one or more Secondary Devices if such devices are present.

It is a further purpose of this invention to provide a policy for the abovementioned devices which controls the functioning of sound, video and data channels of said devices.

Additional purposes of this invention will become apparent as the description proceeds.

Summary of the invention According to the disclosure in this application, one example of Leading Device may be a cellular phone, or any other TCD given by an Authorized User to a Subordinate User, for instance when the Authorized User is an employer and the Subordinate User is an employee.

A Secondary Device, or a number of Secondary Devices, are devices that are subordinate to the Leading Device because the Leading Device determines the way in which they will function end, in particular, the status (enabled/disabled) their Sound-Sound-Data inputoutput channels, as defined hereafter.

Given that the Subordinate User may possess one or more TCDs, for instance a private cellular phone which the Subordinate User ordinarily uses not in the framework of his employment, there may arise a situation in which the Subordinate User could use his private phone or another device, owned or controlled by the Subordinate User (hereafter a “Private Device”), in a way that is not allowed according to the Conversation Policy set by the Authorized User. That might conflict with the expectations or the Policy of his employment.

In order to prevent such a situation in which a Subordinate User circumvents and infringes the Conversation Policy set by the Authorized User, the method described hereafter may be used.

Said method comprises the following steps: The Multiuser Conversation Policy Program is installed into a device (hereafter the “Candidate Device”) designated to be defined as the Leading Device. The Multiuser Conversation Policy Program can be a standalone program, a module integrated in another program, software of any form which is used in any manner by another program, being the Multiuser Conversation Policy Program integrated or made to operatively work in conjunction with the other program in any manner, including by not incorporating or integrating the Multiuser Conversation Policy Program in the other program but by having the other program using the Multiuser Conversation Policy Program by calling it or activating it in the course of the other program’s operation. Additionally, the Multiuser Conversation Policy Program may be hardwired in any device such as integrated circuit (e.g. in a processor, in a SOC etc.}.

Now, for the purpose of illustration only, let us suppose that the Candidate Device is a cellular phone provided by the Authorized User to the Subordinate User, whereby the Authorized User has control over the Leading Device.

The Authorized User selects in the Multiuser Conversation Policy Program the collection of different status (enableddisabled) for each Sound-Sound-Data inputoutput channels (hereafter referred to, in short as “SVD Channels”.

It is clarified that the term “Data” in “Sound-Sound-Data inputoutput channels” means any data or transmission that is not perceivable visually or acoustically by a person. Said Data may be such as resulting in an operation in a device or containing data to be used for performing calculations or generating commands.

The collection of said statuses defined by the Authorized User constitutes the current Policy of the Multiuser Conversation Policy Program. The current Policy may be changed or updated.

The Authorized User, using a Multiuser Conversation Policy Program interface (which may be of any suitable type), may now define the Candidate Device as Leading Device.

In order to do so, the Multiuser Conversation Policy Program, must be installed in a Candidate Device.

The installation of the Multiuser Conversation Policy Program may be done locally, remotely, OTA, hardwired, in a card or memory, storage means, etc..

Moreover, the term “installed” May apply, according to the cases and the different embodiments, to complete installation, partial installation, reinstallation and complete, or partial, updating.

It goes without saying, that the terms “uninstalled” or “removed” mean the opposite of the term “installed”, as described above, with the obvious differences.

It is stressed that a Multiuser Conversation Policy Program to be installed andor used in a Candidate Device, intended to be defined as a Leading Device, and that a Multiuser Conversation Policy Program to be installed andor used in a Candidate Device intended to be defined as a Secondary Device, may be, according to specific embodiments, specific requirements or any consideration: an identical program, (e.g. a full-fledged program), a partial program (that is, a program that comprises only certain portions or modules of the full-fledged Multiuser Conversation Policy Program), a different program (that is, a program that does not share any portions with the Multiuser Conversation Policy Program), and a combination of the above and/or any of the above, wherein certain portions or modules of the Multiuser Conversation Policy Program are locked or disabled temporarily or permanently.

The expression “define the Candidate Device as Leading Device” means they act of enabling the candidate device to operate as Leading Device by using any method available in the Multiuser Conversation Policy Program, e.g. selecting an appropriate option from a menu, clicking a box, setting a flag in any manner, associating the Leading Device status property to a Candidate Device, all the foregoing manually or by vocal command, by transmitting a command, a message or a notification, or by activation of any physical control or mechanism. To remove any doubt, it is clarified that what said above, regarding defining the candidate device as a Leading Device, also applies to setting a Candidate Device as Secondary Device, to setting a Secondary Device as a Leading Device and also applies to any combination thereof.

It is further clarified that the action of defining the status of a device to andor from, Candidate, Leading or Secondary, may be carried out locally or remotely. Moreover, said act of defining the status of a device may be carried out directly or indirectly using an intermediate device, such as a server which sets the status of the devices. Additionally, the status of each device may change automatically, by software means, according to predetermined rules, when a specific scenario occurs, for instance, when an additional, or second Secondary Device is defined and is associated with a previously existing Leading Device that is associated to a first Secondary device, thus changing The Multiuser TCD array.

Lastly, it should be noticed, that if so desired, a TCD may be defined is a Leading Device and one or more other TCDs may be defined as Secondary Device without they need for Authorized User (or any mechanism local or remote, as described above) to set their statuses.

In other words, the status of a TCD to be used in a Multiuser TCD array may be predefined, including at factory level, whereby this predefinition is carried out by software means, optionally in an unchangeable manner and/or it is hardwired (e.g. in a circuit) or by any combination of software and physical means.

Now, if the Authorized User proceeds to define the Candidate Device as the Leading Device, after the Candidate Device has been defined as the Leading Device (and is no longer a Candidate Device), the Authorized User has to indicate some identification information of current Candidate Device to become the first Secondary Device (being the first phone having been defined, at this point of time, as the Leading Device).

Said identification information related to the Candidate Device may consist of any kind of information that allows the Leading Device to send (or transmit in any manner) to the Candidate Device data, commands, updates or any other kind of information (thereafter “Leading Device output to Candidate Device”). The Leading Device output to the Candidate Device, may be transmitted to a Candidate Device using any type of transmission including, for example, one or more of the following: SMS, any form of instant messaging, Wi-Fi, Infrared transmission, Bluetooth kind of information retrievable by the Leading Device Input from Secondary Phone, any acoustic signal, data transmitted through data cable, e.g. a USB cable (provided that the Candidate Device is discoverable and has enabled any kind of transmission necessary for the purpose of sharing some identification information of the Candidate Device with the Leading Device, e.g. by Bluetooth transmission and by Bluetooth discoverability by the part of the Candidate Device).

Examples of Leading Device Input from a Candidate Device, may comprise one or more of the following: Secondary phone number, Mac address, IMEI, data related to a SIM card, etc..

At this point it may be useful to note as follows: In certain cases, Leading Device Input from Candidate Device (e.g. the number of the Candidate Device) is not necessarily required for the purpose of defining the Candidate Device as Secondary Device, since this information may already be available to the Authorized User.

The same consideration applies to the case where the Candidate Device is a private phone, not owned or otherwise controlled by the Authorized User but the owner of the Candidate Device (e.g. a private device) is willing to share this information or in the case that such information is, otherwise, legally obtained.

Any type of the abovementioned transmissions apply to Leading Device output to a Candidate Device and/or to Leading Device Input from Candidate Device and/or, as it will be described later, in this description, between two Secondaries Devices.

Embodiment In this first sample embodiment we will describe, for the sake of simplicity, a case in which all the Multiuser Conversation Policy Programs installed in the TCDs are identical.

This embodiment will be described with reference to the flowchart in Figure 1.

In step 1 of Figure 1, a Multiuser Conversation Policy Programs (or, in brief, “MUCPP”, is installed in a Candidate Device, by an Authorized User.

For the avoidance of any doubt, it is clarified that if a person, which is not an Authorized User, where to perform, even if not permitted to do so, an installation of the Multiuser Conversation Policy Program or set a policy and so forth, said person would still, from the purely technical point of view, qualify as and Authorized User.

The installation may take place in one of the possible manners, as mentioned before.

For the sake of illustration only, we will describe an instance in which the installation is performed manually by an Authorized User.

After the installation of the Multiuser Conversation Policy Program in a Candidate Device takes place in step 10, in step 11 the Authorized User sets the status of the Candidate Device to “Leading Device” e.g., by selecting the appropriate option from the interface of Multiuser Conversation Policy Program.

This can, optionally, be done as a part of the installation process itself in step 10.

Now, in step 12, the Authorized User enables or disables each one of the Sound-Visual-Data Channels (or, in short, “SVD Channels”) of the Leading Device. The statuses for the SVD Channels are “enabled” or disabled”.

Obviously, different or additional terms could be used to name the values of the SVD Channels, e.g., “Default”, whereby the default value is known to be either “enabled” or “disabled”. However, these variations in terminology do not reflect different or additional functional statuses of the SVD Channels.

For the sake of clarity, it is stressed that “change the status” of a SVD Channel and the expression “change the value” of a SVD channel, are equivalent, interchangeable and have the same effect since, by changing the value of a SVD Channel, the status of said SVD Channel is changed as well.

The assignment of the “enabled” value to a SVD Channel means that said SVD Channel is now enabled.

Conversely, the assignment of the “disabled” value to a SVD Channel means that said SVD Channel SVD Channels is now disabled.

To avoid any doubt, it is clarified that both the terms “enabled” and “disabled” are to be construed in the broadest manner in this application.

Thus, for example, by saying that a sound channel is disabled, it is not necessarily meant that said sound channel is inactive or turned off, or that no sound can otherwise be transmitted andor heard through said sound channel.

An instance in which the sound channel is active andor can transmit (either an input or an output) but it is rendered, from a human point of view, impractical or difficult to use, are to be considered, according to this application as being “disabled”. Examples of such an instance, may include, for the sake of example only, one or more of the following: (a) the volume is intentionally lowered significantly; (b) some sounds like, for instance, DTMF tones are played on the sound channel, obstructing it partially or completely; (c) the sound channel is partially or completed jammed although is not inactive.

Similarly, a video channel will be considered “disabled” not only in the event that said channel is inactive or turned off but also, for example only, if: (a) the luminosity of the video channel is intentionally lowered to a level in which it is impractical or impossible to view the output of the video channel; (b) a graphic of any kind is superimposed as to cover the image outputted by the video channel; (c) any activity of the video channel causes the screen to be locked or to be ridirected automatically to a screen unrelated to the content which is supposed to be displayed on the video channel.

Lastly, a data channel will be considered “disabled” not only in the event that said data channel is inactive or unable to transmit data but also in the event that, for the sake of example only, certain activities carried out on the data channel are intentionally impaired. For instance, a USB data cable may be allowed to function as part of a charger but an attempt to transmit any data on said USB data cable may be stopped.

The collection of all the statuses of the SVD Channels, constitutes the current policy (hereafter the “Current Policy” or, simply, “Policy”). When used in relation to the Leading Device, the Current Policy will also be referred to as “Leading Device Policy”. Similarly, when used in relation to a Secondary Device, the Current Policy will also be referred to as “Secondary Device Policy”.

At the moment of the installation, the SVD Channels may have a default value or, in other words, at the moment of the installation there may be a default, predefined, Leading Device Policy or there may be a default, predefined, Secondary Device Policy, according to the case andor according to a specific embodiment.

If the Authorized User, at the moment of the installation, or at any other point of time (e.g. in order to edit the Policy) does not actively change a value of the Policy, the current value is preserved.

Figure 2A shows an example of Leading Device Policy, whereby the only enabled SVD Channel is the automotive head unit, as indicated by 20. The automotive head unit (or, in short “head unit”), also commonly referred to as “infotainment” or “infotainment system”), may be of any type used in a car e.g. iOS or Android based, such as CarPlay or Android Auto or may be based on any different operating system or any other software, e.g. a non-Android, non-iOS aftermarket head unit’s native software.

In light of the current Leading Device Policy, as in Figure 2A, the user of the Leading Device will be able to use exclusively the functionalities of head unit 20 but not those of any other SVD Channel.

Now the Authorized User has the option, as indicated in 13 of figure 1, to define another TCD (which is not the Leading Device, but a Candidate Device) for it to become a Secondary Device.

If he/she chooses to do so, as indicated in 13a of figure 1, the Multiuser Conversation Policy Program is installed, in step 14 of figure 1, in a new Candidate Device (since the former Candidate Device has become, by now, the Leading Device) and in step of figure 1, the Authorized User sets the status of the new Candidate Device to “Secondary Device” e.g., by selecting the appropriate option from the interface of the Multiuser Conversation Policy Program, which interface may be of any convenient form.

Then, in step 16 of figure 1, the Authorized User enables andor disables SVD Channels of the Secondary Device, using a procedure similar to that used for the Leading Device.

As already mentioned, the current example assumes that the Authorized User enables or disables manually each one of the Sound-Visual-Data Channels. It is, however, stressed that in the event that the Secondary Device is found in a remote location, the values of SVD Channels of the Secondary Device may be set using any of the customary and suitable methods for this purpose including OTA or transmitting from a dedicate server a configuration file. In a very simple example, even an SMS could serve the purpose. Such an SMS, sent by the Leading Device, could contain data readable by the receiving device (that is, the Secondary Device) in the form of a code identifying each SVD Channel (e.g. a number identifying the SVD Channel) and a value (e.g. “0” for “disabled” and “1” for “enabled”.

Steps 13 to 16 of Figure 1 may be repeated as many times as required, to define additional Secondary Devices and enable andor disable their SVD Channels.

In the example given in Figure 2B, for illustration only, the Authorized User sets the value of all the SVD Channels of the Secondary Device to “disabled”, or, in other words the authorized user disables all the SVD channels of the Secondary Device.

This may be done for a variety of reasons, e.g. if the Authorized User requires the user of the Secondary Device (being the user of the Secondary Device generally, but not necessarily, a Subordinate User) not to use the Secondary Device, instead of the Leading Device, in the attempt to try to circumvent a Policy set by the Authorized User.

Let's suppose, for example, that a Subordinate User, is given by the Authorized User, in the framework of an employer-employee relationship, a Leading Device and that the Policy of the Leading Device is such that the Subordinate User can, for safety reasons - such as to avoid distractions while driving - use exclusively the head unit as he/she drives. If the Subordinate User possesses or carries with himself/herself a private phone which can be used in a dangerous way while driving, he/she may be tempted to do so, even if this is contradictory to the Leading Device Policy. In order to avoid such behavior, the Authorized User may disable all the SVD channels of the Subordinate User’s private phone, provided that the Subordinate User’s private phone has been defined as a Secondary Device.

This scenario, as described above, is illustrated in Figure 2B where it is shown that all the SVD channels of the Secondary Device (indicated as “Secondary Device 1”) are disabled.

Now, some observations may be in order.

The Leading Device and the Secondary Device described above (Secondary Device 1), form what will be called hereafter “TCD array”. So far in the description there are two members inside the TCD array that is, the Leading Device and the secondary device (Secondary Device 1).

Having said that, the TCD array may consist of a single device, being said device the Leading Device.

The TCD array may, on the other hand, consist of multiple devices, that is, N devices as shown also in figure 2B.

In other words, there may be a concatenation of Secondary Devices. It should be noted that Secondary Devices may differ in their Policy and that said Policy may, according to certain embodiments, dynamically change and/or be dependent on a variety of occurrences, as it will be detailed in additional embodiments of this disclosure.

Furthermore, it should be noticed that the order or the chronology of the concatenation of Secondary Devices in a TCD array is not indicative nor does it influence or create any hierarchy, if any such hierarchy exists, between them.

Moreover, it is stressed that the status of a Secondary Device may be changed dynamically to Leading Device as the Leading Device status changes to Secondary Device.

For the avoidance of any doubt, it should be noted that a Subordinate User cannot change the Policy for a Secondary Device or a Leading Device since the Multiuser Conversation Policy Program is, preferably, equipped with password or a biometric identification or any other method that grants the Authorized User exclusive capability to set or change a Policy.

It should also be noted that the Multiuser Conversation Policy Program is equipped with a feature that prevents the Subordinate User from removing the Multiuser Conversation Policy Program.

Moreover, since all the devices in the TCD array can, optionally, be monitored by a dedicated remote dashboard, any attempt to remove the Multiuser Conversation Policy Program would be detected.

Since the Multiuser Conversation Policy Program may be equipped with a feature that prevents any user from turning off the Bluetooth of the TDC (e.g. by implementing a loop that checks constantly and cyclically the status of the Bluetooth transmitter and turns it on should it be off) or any other connectivity means if such are needed for the fulfilling of any of the embodiments with this invention, the abovementioned remote dashboard or any other equivalent program would detect a technical failure or an intentional malfunctioning of said connectivity means.

Embodiment As it can be readily appreciated, in certain cases some of the SVD channels, e.g. an automotive head unit, a tablet or even a smartwatch, have considerable telecommunication capabilities which are independent from a TCD with which they are coupled with.

For example, certain automotive head units can host a SIM card and have complete autonomous functionalities for carrying out phone calls, messaging etc.

In any case, many of the SVD channels have significant computing resources that would allow them the installation and functioning of a Multiuser Conversation Policy Program.

Consequently, in certain cases, for example in the case of an automotive head units, a SVD channel equipped with a Multiuser Conversation Policy Program, could be one of the devices belonging to the TCD array and could function as the Leading Device or as a Secondary Device, according to what described above, including in Embodiment 1.

It is understood that a SVD channel, capable of functioning as the Leading Device or as a Secondary Device could also, if so desired, to operate as a regular SVD Channel.

In this case, a Multiuser Conversation Policy Program interface, may include the status of “SVD Channel”, in addition to the status “Leading Device” and the status “Secondary Device”.

Any of these three statuses could, in this case, be selected and the statuses could be toggled (that is, only one status can be defined at any given time) according to the case.

Embodiment According to another embodiment of the invention described in this disclosure, devices such a road traffic control device could provide data that would influence the andor change, temporarily, the value of one or more SVD Channels and could, in certain cases, be considered themselves as SVD Channels.

Streetlights and traffic markers have become increasingly capable of Li-Fi, GSM and the other kinds of communications, including with vehicles themselves.

For example, the article “Adaptive Traffic Lights Using Car-to-Car Communication” (Conference: Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th Authors: V . Gradinescu, C. Gorgorin, V . Cristea, Polytechnic University of Buchares) describes an adaptive traffic light system based on wireless communication between vehicles and fixed controller nodes deployed in intersections.

Also, it is known for streetlights to be GSM capable, as described, for instance in “STREET LIGHT CONTROLLER WITH GSM TECHNOLOGY” by H. P. Khandagale International Journal of Engineering (Applied Sciences and Technology, 2020 V ol. 4, Issue 10, ISSN No. 2455-2143, Pages 268-271) where control the on-off street lights via short message service (SMS) is described.

In view of these facts, devices such a Road traffic control devices could provide data that would influence the Multiuser Conversation Policy Program andor change, temporarily, the value one or more SVD channels.

For example, if suitable data is provided to the Multiuser Conversation Policy Program in the form of an SMS or a signal of any kind, including acoustic ones, the Multiuser Conversation Policy Program could respond to said data by changing, temporarily or for any length of predetermined time, the value of one or more of the SVD Channels of devices of the TCD array.

For instance, when a vehicle of any kind, or even a pedestrian, approach a streetlight that is about to change to red, one or more of the SVD Channels could be automatically changed by the Multiuser Conversation Policy Program. For instance, following such data received from a streetlight, the screen of the device on which the Multiuser Conversation Policy Program operates, could be temporarily disabled in order to avoid visual distraction by part of the User.

The way of disabling or enabling one or more of the SVD Channels would remain as illustrated above, and in particular, in the previous embodiments.

Embodiment TCD users and, in particular, cellular phone users have become increasingly aware and vulnerable to an additional hazard posed by the use of these devices, that is, the risk of loss of privacy and data security due to hackers.

It is well known that malicious software is capable of activating remotely different channels of cellular phones and by doing that, it is possible to listen illegally to conversations of phone owners and even observe them or take pictures using the phone’s owner, while the latter is totally unaware of this breach of privacy.

The Multiuser Conversation Policy Program may provide a tool for limiting digital intrusion perpetrated by hackers.

For example, the Policy of one or more TCD’s equipped wait for the Multiuser Conversation Policy Program may be set as to disable certain or all SVD Channels of a Leading Device andor of Secondary Device when privacy is required, e.g. during a sensitive business meeting.

This can be done automatically, for example implementing geofences functions or time frames.

Alternatively, the interface Multiuser Conversation Policy Program may comprise a control e.g. a button or a voice command, that toggles some or all the SVD Channels from “enabled” to “disabled” and vice versa.

Claims (7)

Claims Claim Method for enabling the configuration of an array of telecommunication devices consisting of, at least, a Leading Device which influences one or more Secondary Device, if such Secondary Devices are present, comprising the following steps:

1. Providing in a Candidate Device a Multiuser Conversation Policy Program;

2. Setting the status of the Candidate Device to become a Leading Device;

3. Enabling or disabling each of the Sound-Video-Data Channels of the Leading Device;

4. Optionally Providing in a different Candidate Device a Multiuser Conversation Policy Program;

5. Setting the status of the Candidate Device to become a Secondary Device;

6. Enabling or disabling each of the Sound-Video-Data Channels of the Secondary Device and

7. Repeating steps 4 to 6 for each additional Secondary Device is so desired. Claim Method according to Claim 1 whereby a SVD Channel equipped with a Multiuser Conversation Policy Program functions as the Leading Device or as a Secondary Device. Claim Method according to any one of claims 1 or 2 whereby the Multiuser Conversation Policy Program can assign to an SVD Channel or to a TCD, any of the following statuses: Leading Device, Secondary Device and SVD Channel and whereby said statuses can be toggled. Claim Method according any one of claim 1 to 3 whereby an automotive head unit may be set to be a Leading Device. Claim Method according any one of claims 1 to 4 whereby a road traffic control device provides data that may influence the Policy of a Leading Device andor of a Secondary Device. Claim Method according any one of claims 1 to 5 whereby the Policy of the Multiuser Conversation Policy Program is set and activated to counter digital intrusion.