REFERENCE TO CO-PENDING APPLICATIONS

Priority is claimed from US provisional applications USSN 62528094, entitled "System and Methods for Automated Remote Operation and Troubleshooting of

Devices", filed by Yaakov Shoshan on Ol-JUL-2017 and from USSN 62544868, titled "System and Methods for Session Management of Virtual Troubleshooting Agents", filed by Yaakov Shoshan on 13-AUG-2017, the disclosures of which applications are hereby incorporated by reference,

FIELD OF THE INVENTION

This invention relates generally to device maintenance and more specifically to remote operation and troubleshooting of a device.

BACKGROUND OF THE INVENTION

Automated troubleshooting systems are known. Troubleshooting technology generally is described in Wikipedia: https://en.wikipedia.org/wiki/Troubleshooting.

The industrial and information eras have brought about tremendous changes in the number of devices (e.g. tools or "things") each person has in his/her possession (in his/her surroundings, such as at home, or in a car or office). Various devices are used for various purposes, such as in the kitchen (e.g. oven, micro-oven, refrigerator, dishwasher), for entertainment (e.g. TV, audio system, lights), for healthcare (e.g. heart monitoring devices, blood-pressure gauge, diabetes meter, blood saturation meter, etc.), for digital communication and lifestyle (personal computers, laptops, smartphones, tablets, routers, switches, modems, printers, scanners, etc.) or for other purposes (e.g. air-conditioners, hairdryers, shavers, etc.). There are various types of devices, such as the aforementioned electrical devices, and other non-electrical (e.g. mechanical) devices such as taps, furniture, and other passive tools. Each of these devices has its own operation procedures and malfunctions that may occur in the event of failure. Usually there is a printed or on-line manual that the device's user may use in order to understand its operation, or to refer to troubleshooting methods for several stated known problems. Some people have difficulty in using these manuals in order to handle their problem (whether related to an operation procedure, or solving a device failure). Another option that is usually common these days is to call or contact (e.g. by using voice call, SMS or instant messaging application) a technical support agent that guides the user/customer remotely on how to solve his/her technical issue.

Automatic technologies are described in patent document US2012031 1074A1 2012-12-06 entitled Methods for Displaying Content on a Second Device that is Related to the Content Playing on a First Device, and in patent document US20150215668.

The disclosures of all publications and patent documents mentioned in the specification, and of the publications and patent documents cited therein directly or indirectly, are hereby incorporated by reference. Materiality of such publications and patent documents to patentability is not conceded

SUMMARY OF CERTAIN EMBODIMENTS

As the number of personal devices continues to grow on a world-wide scale, especially in the near future, as the IOT (Internet-Of-Things) matures, the load on contact centers accordingly grows extensively, and will likely result both in dissatisfaction of the users/customers (e.g. longer waiting time), and also in heavy OPEX (operation expenses) of the technical service providers.

In parallel, in the past few years there have been great advances in artificial intelligence technology that can be used for problem solving or for human interaction replacement.

Certain embodiments seek to provide a new? system architecture, methods and apparatus which are characterized by automation of the remote technical support.

Certain embodiments seek to provide systems, computer program products and methods for session management of virtual troubleshooting agents.

Certain embodiments seek to provide Automated Remote help for and/or Troubleshooting of Devices with Session Management of Virtual Troubleshooting Agents seeks to provide an Automated Remote Technical Support (ARTS) system for automated session management of a technical problem, comprising: next action selector (NAS) that at least once selects a next action to be executed within a sessions, the NAS may use a model that represents the information of the ARTS system regarding current status of the world model, the next action's type may be M2M, M2H, M2M & M2H action types, if an M2H action is chosen as a next action, the action may be further processed by a Next Message Generator (NMG) to prepare the next message to be presented to the user, the model may comprise s Probabilistic Graphical Model.

Certain embodiments seek to provide an automated remote technical support (ARTS) system which can interact with human entity via auis e.g. m2h, and/or can conduct electronic dialogue with device entities via an lis e.g. m2m 140 which may have a multiplicity protocols via which m2ml40 communicates with a multiplicity of device types respectively, where a single device type may comprises a particular model number of a device having a particular function (washing machine, television, or ecg device, diabetes pump or other healthcare device) of appliance or piece of equipment, such as a HP workstation model number such-and-such or an Amana refrigerator model number such- and-such, for example, or, an entire family or series of models, by a single manufacturer or a consortium of such, may all be programmed to communicate via a single protocol .

Certain embodiments of the present invention seek to provide circuitry typically comprising at least one processor in communication with at least one memory, with instructions stored in such memory executed by the processor to provide functionalities which are described herein in detail. Any functionality described herein may be firmware- implemented or processor-implemented as appropriate .

Certain embodiments of the present invention seek to provide automatic and remote diagnostic and healthcare processes e.g. because the number of people who need healthcare is on the rise and the number of healthcare personnel (doctors, nurses, technicians, etc.) is not commensurate .

It is appreciated that any reference herein to, or recitation of, an operation being performed is, e.g. if the operation is performed at least partly in software, intended to include both an embodiment where the operation is performed in its entirety by a server A, and also to include any type of "outsourcing" or '"cloud ^" embodiments in which the operation, or portions thereof, is or are performed by a remote processor P (or several such), which may be deployed off-shore or ' ^" on a cloud", and an output of the operation is then communicated to, e.g. over a suitable computer network, and used by, server A. Analogously, the remote processor P may not, itself, perform all of the operations, and, instead, the remote processor P itself may receive output/'s of portion/s of the operation from yet another processor/s P', may be deployed off-shore relative to P, or "on a cloud", and so forth.

The present invention thus typically includes at least the following embodiments: Embodiment a: A system (e.g. (ARTS) for automated session management of a technical problem comprising a "next action selector (NAS)" processor configured to select a next action to be executed using a model that represents information possessed by the ARTS system, regarding current status of a world model.

Embodiment b: a system or processor according to any of the preceding embodiments wherein the next action comprises one of: M2M, M2H, M2M & M2H action types.

Embodiment c: a system or processor according to any of the preceding embodiments wherein if the next action is of the M2H action type, the action is further processed by a "Next Message Generator (NMG)" processor, to yield a next message to be presented to the user.

Embodiment d: a system or processor according to any of the preceding embodiments wherein the model comprises a Probabilistic Graphical Model.

The present invention also typically includes at least the following embodiments:

Embodiment 1. A remote technical support system comprising:

troubleshooting logic programmed onto a processor:

device-communication logic programmed onto a processor and configured to support establishment of (or establish) at least one communication route aka channel over which device-generated data can be communicated to the troubleshooting logic; human -communication logic programmed onto a processor and configured to support establishment of (or establish) at least one communication route aka channel over which human inputs can be communicated to the troubleshooting logic: and

session communication management logic programmed onto a processor and determining, for each of a multiplicity of technical support sessions, if, when and with which device to activate the device-communication logic and if, when and via which input/output device/s to activate the human -communication logic.

It is appreciated that any subset of the operations of Figs. 6, 9 and any subset of the functional units of Fig. 1 - 6 may if desired be incorporated into or included in the troubleshooting logic. Also, any subset of the operations of Figs. 6, 9 and any subset of the functional units of Fig. 1 - 6 may if desired be incorporated into or included in the device- communication logic. Also, any subset of the operations of Figs. 6, 9 and any subset of the functional units of Fig. 1 - 6 may if desired be incorporated into or included in the human -communication logic. Also, any subset of the operations of Figs. 6, 9 and any subset of the functional units of Fig. 1 - 6 may if desired be incorporated into or included in the session communication management logic

For example, the troubleshooting (TS) logic may be the logical or functional portion of the session manager s/s (e.g. subsystem) [ 130] e.g. as shown in Fig. 6. The TS logic may include the world model handler [632] and the next action selector [631] . The TS logic may also include DB storing session management data such as but not limited to all or any subset of the following: current and past world model status, all actions taken, user answers to the ARTS messages (textual and/or voice and/or image and/or video), and respon ses of devices to M2M logical interaction interface actions. The device-communication logic may be, or may include, or may be included in, the M2M logical interaction interface [140] . The human -communication logic may be, or may include, or may be included in, the M2H User Interaction S/S [120] . The session communication management logic may be, or may include, or may be included in, the session manager s/s [130] . For example, The session communication management logic may be, or may include, or may be included in, the Next Action Selector [631] that may select the type of action (e.g. logical action or user- interaction action).

It is appreciated that one or any one of the above 4 logical units (e.g. troubleshooting logic, device-communication logic, human -communication logic, session communication management logic) may receive inputs from all or any subset of, the remaining 3 units, and/or from any data repository available e.g. As described herein, thereby to facilitate efficient system functioning. In other words, one or all of the above 4 logical units may change course, upon receipt of input from one or any of the remaining 3 logical units. For example, the trouble-shooting logic may change course upon receipt of inputs from the device-communication logic and/or from the human-communication logic, and/or from the session communication management logic. Similarly, the session communication management logic may change course upon receipt of inputs from the device- communication logic and/or from the human -communication logic, and/or from the trouble-shooting logic. Similarly, the device- and/or human -communication logic may change its course upon receipt of inputs from the session communication management logic and/or from the trouble-shooting logic and/or from one another.

Examples: the session management activates or re-activates a certain channel, upon receipt of an indication from the troubleshooting logic thai a root cause

hypothesis has failed, or that no root cause hypothesis can yet be generated, hence more data is needed from the scene of the malfunctioning device. And/or, the troubleshooting logic makes at least one choice between exploitation (making the best decision given current data) and exploration: gather more information before making decision), the exploitation-exploration choice, as well as selection of the best decision and determination of what additional information to gather, can all be affected by inputs from any of the above 3 logic units other than the troubleshooting logic itself, and/or may be based on data from the data repositories shown and described herein e.g. on experience vis a vis a certain device, device type or end -user, e.g. as stored in the session dataset or end -user dataset.

Embodiment 2. A system according to any of the preceding embodiments wherein the device-communication logic is operative to at least one support establishment of at least one communication route aka channel over which data generated by a device other than a faulty device, can be communicated to the troubleshooting logic.

for example, the troubleshooting logic can request from the session logic, data regarding communication between a malfunctioning television and the internet, and responsively, a route over which a router in the television's vicinity can communicate measured data regarding communication between the malfunctioning television and the internet, may be communicated to the troubleshooting logic.

Embodiment 3. A system according to any of the preceding embodiments wherein the troubleshooting logic communicates with the session communication management logic including at least once prompting the session communication management logic , mis-session, to activate the device communication logic for a given device.

Embodiment 4. A system according to any of the preceding embodiments wherein at least one route includes a sequence of route segments including one internet route segment and one cellular segment.

Embodiment 5. A system according to any of the preceding embodiments wherein the system has access to a data repository storing devices and, for at least some devices, respective (known or hypothesized) associations thereof with individual end- users and wherein the session communication management logic at least once consults the data repository and selects therefrom at least one device for which a communication route should be established , to enable data generated by that device to be communicated to the troubleshooting logic.

For example, the data repositorv' may store, for example, data indicating that joe has a router, model number such and such, connected to or adjacent to or co-owned by or otherwise associated with his television, if joe then contacts the system and complains about his television, the session communication management logic may become aware of the existence of joe's router by consulting the data repository and may select the router as the or a device for which a communication route should be established , to enable data generated by the router to be communicated to the troubleshooting logic.

Embodiment 6. A system according to any of the preceding embodiments wherein at least some of the troubleshooting logic is deployed locally, in end-users' respective homes, thereby to facilitate troubleshooting even in the absence of internet or cellular communication routes.

Embodiment 7. A sy stem according to any of the preceding embodiments wherein the session communication management logic receives an im age of a device from the end-user via a communication route, uses image processing to determine at least one visual characteristic of the device, compares the visual characteristic to stored visual characteristics of known devices, wherein at least one of the device's function, manufacturer, and model number is stored for each known device, and wherein the session communication management logic identifies at least one of the device's function, manufacturer and model number accordingly.

Embodiment 8. A system according to any of the preceding embodiments wherein the session communication management logic uses at least one user experience consideration to determine, for at least one technical support session, when and how to activate the human -communication logic.

For example, the session communication management logic may at least once prompt the end-user, in a single communication, to send in images or recordings, using his phone, of "whatever is not working", rather than issuing a sequence of

communications, say , to image portion x of the device and then portion y. then the session communication management logic provides all resulting images or recordings to the troubleshooting logic which analyzes these and derives information therefrom, only in a minority of scenarios e.g. only if the images sent in are deemed insufficient and a specific image deemed lacking by the troubleshooting logic, does the session communication management logic revert to the end-user to request that specific image, in many cases, this logic may result in the user intuitively imaging a few images from which, in combination, the necessary information for troubleshooting may be derived, without having to be prompted laboriously as to exactly what to image.

The term "phone" and derivatives as used herein can be replaced if and as appropriate by: playstation, iPad, TV, remote desktop computer, game console, tablet, mobile e.g. laptop or other computer terminal, embedded remote unit.

Embodiment 9. A system according to any of the preceding embodiments wherein the session communication management logic communicates with the user via a user interface and wherein the session communication management logic at least once receives at least one image (still or video) data file , to characterize the malfunction, from the user via the user interface and wherein the system is configured to allow the data file to be generated within the system, such that the end-user generates the at least one image from inside the system, without leaving the GUI to operate her or his camera, and without having to upload resulting the data file into the system.

Embodiment 10. A system according to any of the preceding embodiments wherein the session communication management logic communicates with the user via a user interface and wherein the session communication management logic at least once receives at least one audio data, file (e.g. recording of malfunctioning device or spoken natural language description of the malfunction) , to characterize the malfunction, from the user via the user interface and wherein the system is configured to allow the data file to be generated within the sy stem, such that the end-user records the audio data file, from inside the system, without leaving the GUI to operate her or his microphone, and without having to upload the data file into the system.

Embodiment 11. A system according to any of the preceding embodiments wherein the troubleshooting logic resides on a cloud.

Embodiment 12. A system according to any of the preceding embodiments wherein the session communication management logic resides on a cloud.

Embodiment 13. A system according to any of the preceding embodiments wherein the device- and/or human-communication logic is operative to establish at least one internet-only communication route if no cellular communication is available with a given faulty device and user thereof, and to establish at least one cellular-only communication route if no internet communication is available with a given faulty device and user thereof.

Embodiment 14, A system according to any of the preceding embodiments wherein the system includes a device database storing at least one of geographical locations of devices including at least one outdoor device and functional relationships between devices including at least one outdoor device (such as a neighborhood switchboard or other component of an external aka outdoor data network) and wherein the troubleshooting logic at least once generates at least one hypothesis which regards the outdoor device as a root cause for malfunctioning of at least one indoor device.

Embodiment 15. A method for providing computerized remote technical support, the method comprising;

Providing troubleshooting logic programmed onto a processor;

Using at least one processor, establishing at least one communication route aka channel over which device-generated data can be communicated to the troubleshooting logic;

Establishing at least one communication route aka channel over which human inputs can be communicated to the troubleshooting logic; and

determining, for each of a multiplicity of technical support sessions, if, when and with which device to activate the device-communication logic and if, when and via which input/output device/s to activate the human -communication logic.

Embodiment 16. A computer program product, comprising a non-transitory tangible computer readable medium having computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a method for providing computerized remote technical support, the method comprising:

Providing troubleshooting logic programmed onto a processor;

Using at least one processor, establishing at least one communication route aka channel o ver which device-generated data can be communicated to the troubleshooting logic;

Establishing at least one communication route aka channel over which human inputs can be communicated to the troubleshooting logic; and

determining, for each of a multiplicity of technical support sessions, if, when and with which device to activate the device-communication logic and if, when and via which input/output device/s to activate the human -communication logic. A "problem" or "technical problem" can (in addition to an operational problem of a device) can be a problem in human bodily function such as a disease, health problem or a symptom of a health problem that the human being may feel or suffer from.

Also pro vided, excluding signals, is a computer program comprising computer program code means for performing any of the m ethods shown and described herein when the program is run on at least one computer; and a computer program product, comprising a typically non-transitory computer-usable or -readable medium e.g. non- transitor - computer -usable or -readable storage medium, typically tangible, having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement any or all of the methods shown and described herein. The operations in accordance with the teachings herein may be performed by at least one computer specially constructed for the desired purposes or general purpose computer specially configured for the desired purpose by at least one computer program stored in a typically non-transitory computer readable storage medium. The term "non- transitory" is used herein to exclude transitory, propagating signals or waves, but to otherwise include any volatile or non-volatile computer memory technology suitable to the application.

Any suitable processor/s, display and input means may be used to process, display e.g. on a computer screen or other computer output device, store, and accept information such as information used by or generated by any of the methods and apparatus shown and described herein; the above processor/s, display and input means including computer programs, in accordance with some or all of the embodiments of the present invention. Any or all functionalities of the invention shown and described herein, such as but not limited to operations within flowcharts, may be performed by any one or more of: at least one conventional personal computer processor, workstation or other programmable device or computer or electronic computing device or processor, either general-purpose or specifically constructed, used for processing; a computer display screen and/or printer and/or speaker for displaying; machine-readable memory such as optical disks, CDROMs, DVDs, BluRays, magnetic-optical discs or other discs; RAMs, ROMs, EPROMs, EEPROMs, magnetic or optical or other cards, for storing, and keyboard or mouse for accepting. Modules shown and described herein may include any one or combination or plurality of: a server, a data processor, a memory/computer storage, a communication interface, a computer program stored in memory/computer storage. The term "process" as used above is intended to include any type of computation or manipulation or transformation of data represented as physical, e.g. electronic, phenomena which may occur or reside e.g. within registers and /or memories of at least one computer or processor. Use of nouns in singular form is not intended to be limiting; thus the term processor is intended to include a plurality of processing units which may be distributed or remote, the term server is intended to include plural typically interconnected modules running on plural respective servers, and so forth .

The above devices may communicate via any conventional wired or wireless digital communication means, e.g. via a wired or cellular telephone network or a computer network such as the Internet.

The apparatus of the present invention may include, according to certain embodiments of the invention, machine readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements some or all of the apparatus, methods, features and functionalities of the invention shown and described herein. Alternatively or in addition, the apparatus of the present invention may- include, according to certain embodiments of the invention, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any of the teachings incorporated herein may, wherever suitable, operate on signals representative of physical objects or substances.

The embodiments referred to above, and other embodiments, are described in detail in the next section.

Any trademark occurring in the text or drawings is the property of its owner and occurs herein merely to explain or illustrate one example of how an embodiment of the invention may be implemented.

Unless stated otherwise, terms such as, "processing", "computing", "estimating", "selecting", "ranking", "grading", "calculating", "determining", "generating",

"reassessing", "classifying", "generating", "producing", "stereo-matching", "registering", "detecting", "associating", "superimposing", "obtaining", "providing", "accessing", "setting" or the like, refer to the action and/or processes of at least one computer/s or computing system/s, or processor/s or similar electronic computing device/s or circuitry, that manipulate and/or transform data which may be represented as physical, such as electronic, quantities e.g. within the computing system's registers and/or memories, and/or may be provided on-the-fly, into other data which may be similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices or may be provided to external factors e.g. via a suitable data network. The term "computer" should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, embedded cores, computing system, communication devices, processors (e.g. digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) and other electronic computing devices. Any reference to a computer, controller or processor is intended to include one or more hardware devices e.g. chips, which may be co-located or remote from one another. Any controller or processor may for example comprise at least one CPU, DSP, FPGA or ASIC, suitably configured in accordance with the logic and functionalities described herein.

The present invention may be described, merely for clarity, in terms of terminology specific to, or references to, particular programming languages, operating systems, browsers, system versions, individual products, protocols and the like. It will be appreciated that this terminology or such reference/s is intended to convey general principles of operation clearly and briefly, by way of example, and is not intended to limit the scope of the invention solely to a particular programming language, operating system, browser, system version, or individual product or protocol. Nonetheless, the disclosure of the standard or other professional literature defining the programming language, operating system, browser, system version, or individual product or protocol in question, is incorporated by reference herein in its entirety.

Elements separately listed herein need not be distinct components and

alternatively may be the same stmcture. A statement that an element or feature may exist is intended to include (a) embodiments in which the element or feature exists; (b) embodiments in which the element or feature does not exist; and (c) embodiments in which the element or feature exist selectabiy e.g. a user may configure or select whether the element or feature does or does not exist.

Any suitable input device, such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein . Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein. Any suitable processor/s may be employed to compute or generate information as described herein and/or to perform functionalities described herein and/or to implement any engine, interface or other system described herein. Any suitable computerized data storage e.g. computer memory may be used to store information received by or generated by the systems shown and described herein. Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any other computeri zed components shown and described herein may communicate between themselves via a suitable computer network.

Abbreviations include:

ACS = Access Control Server

Bayesian network (BN) - e.g. in fig. 9

customer relationship management (CRM)

Next Action Selector (NAS) - intended to include logic, residing on a processor, for selecting a new action in a troubleshooting session

Next Message Generator (NMG) - intended to include logic, residing on a processor, for generating a new message in a troubleshooting session

PGM (Probabilistic graphical model)

PPI: product provisioning interface or other electronic communication RVD - Random variable distribution

TPRV - target problem random variable

User Interaction Software (UISW)

Logical Interaction Subsystem or "LIS"

Subsystem = S/S.

M2H (Machine-to-Human)

User Interaction Subsystem; UIS

Automated Remote Technical Support (ARTS)

BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the invention and to see how it may be carried out in practice, embodiments will now be described, by way of non-limiting example only , with reference to the accompanying drawings, in which: Fig. 1 illustrates schematically the block diagram of the Automated Remote Technical Support (ARTS) System and sub-systems, all of any subset of which may be provided;

Fig. 2 presents an overall scenario in which an ARTS system e.g. that of Fig. 1 , may be operated;

Figs. 3, 3b and 3c present examples of optionally two links between two ARTS system Interaction subsystems (User/Logical), each e.g. as described herein, and relevant destinations, for embodiments of the present invention;

Fig. 4 presents another example of optionally two links between M2M Logical Interaction subsystems and the relevant destination, for embodiments of the present invention;

Fig. 5 presents another example of optional links between M2M Logical Interaction subsystems and relevant destinations, including using the User Interaction Device (e.g. smartphone), for embodiments of the present invention;

Fig. 6 presents an example block diagram and flow of part of the Session Manager subsystem and the M2H User Interaction subsystem; all blocks and all flow operations, or any subset thereof respectively, may be provided;

Fig. 7 presents an example of (part of) a chat session which may form (part of) the automated remote troubleshooting session;

Fig. 8 illustrates an example of a small basic probabilistic graphical model of an electronic device, including CPT of one of its nodes; and

Fig. 9 presents a simplified flow diagram of an example troubleshooting session in accordance with certain embodiments; all or any subset of illustrated elements may be provided, in any suitable order e.g. as shown; e.g. in conjunction with any of the embodiments shown and described herein.

In the block diagrams, arrows between modules may be implemented as APIs and any suitable technology may be used for interconnecting functional components or modules illustrated herein in a suitable sequence or order e.g. via a suitable API/Interface. For example, state of the art tools may be employed, such as but not limited to Apache Thrift and Avro which provide remote call support. Or, a standard communication protocol may ^¬ be employed, such as but not limited to HTTP or MQTT, and may be combined with a standard data format, such as but not limited to JSON or XML. Methods and systems included in the scope of the present invention may include some (e.g. any suitable subset) or all of the functional blocks shown in the specifically illustrated implementations by way of example, in any suitable order e.g. as shown.

Computational, functional or logical components described and illustrated herein can be implemented in various forms, for example, as hardware circuits such as but not limited to custom VLSI circuits or gate arrays or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one tangible or intangible computer readable medium and executable by at least one processor, or any- suitable combination thereof. A specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question. For example, the component may be distributed over several code sequences such as but not limited to objects, procedures, functions, routines and programs and may originate from several computer files which typically operate synergistically.

Each functionality or method herein may be implemented in software (e.g. for execution on suitable processing hardware such as a microprocessor or digital signal processor), firmware, hardware (using any conventional hardware technology such as Integrated Circuit technology) or any combination thereof.

Functionality or operations stipulated as being software -implemented may alternatively be wholly or fully implemented by an equivalent hardware or firmware module and vice-versa. Firmware implementing functionality described herein, if provided, may be held in any suitable memory device and a suitable processing unit (aka processor) may be configured for executing firmware code. Alternatively, certain embodiments described herein may be implemented partly or exclusively in hardware in which case some or all of the variables, parameters, and computations described herein may be in hardware.

Any module or functionality described herein may comprise a suitably configured hardware component or circuitry. Alternatively or in addition, modules or functionality described herein may be performed by a general purpose computer or more generally by a suitable microprocessor, configured in accordance with: methods shown and described herein, or any suitable subset, in any suitable order, of the operations included in such methods, or in accordance with methods known in the art.

Any logical functionality described herein may be implemented as a real time application if and as appropriate and which may employ any suitable architectural option such as but not limited to FPGA, ASIC or DSP or any suitable combination thereof. Any hardware component mentioned herein may in fact include either one or more hardware devices e.g. chips, which may be co-located or remote from one another.

Any method described herein is intended to include within the scope of the embodiments of the present invention also any software or computer program performing some or all of the method's operations, including a mobile application, platform or operating system e.g. as stored in a medium., as well as combining the computer program, with a hardware device to perform some or all of the operations of the method.

Data can be stored on one or more tangible or intangible computer readable media stored at one or more different locations, different network nodes or different storage devices at a single node or location .

It is appreciated that any computer data storage technology, including any type of storage or memory and any type of computer components and recording media that retain digital data, used for computing for an interval of time, and any type of information retention technology, may be used to store the various data provided and employed herein. Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or off-line; which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use; and which is based on any suitable technologies such as semiconductor, magnetic, optical, paper and others.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS in the drawings and descriptions set forth, identical reference numerals indicate those components that are common to different embodiments or configurations.

As used herein, the phrase "for example," "such as", "for instance", "e.g.", and variants thereof describe non-limiting embodiments of the present invention. Reference in the specification to "one implementation", "some implementations", "certain implementations", "other implementations", "another implementations", "one embodiment", "an embodiment", "some embodiments", "another embodiment", "other embodiments", "certain embodiments", "one instance", "some instances", "one case", "some cases", "other cases" or variants thereof means that a particular feature, structure or characteristic described in connection with the embodiment(s) is included in at least one embodiment of the invention. Thus the appearance of the phrase "one embodiment", "an embodiment", "some embodiments", "another embodiment", "certain embodiments", "other embodiments", "one instance", "some instances", "one case", "some cases", "other cases" or variants thereof does not necessarily refer to the same embodiment(s).

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

Note that the description below refers to devices. Typical, yet not exclusive, examples of devices are mentioned herein and may also include laptop, router, switch, smartphone, mobile telephone, laptop dongle facilitating access of laptop to cellular network, laptop connectibie to cellular networks and/ or any device (e.g. medical) that may form part of a cellular or terrestrial network (such as the Internet or other private network).

The description below is provided with reference to distinct system architectures (in the following Figures). The invention is by no means bound to the specified architectures and or to the specific blocks included in the different architectures.

Figure 1 is an illustration of an example of the Automated Remote Technical Support (ARTS) system [100] high level block diagram and interfaces. The ARTS system may optionally interact with one or more entities according to several embodiments listed hereunder. Fig. 1 presents an example of two types of entities with which ARTS interact: a Human User using his/her interaction device [150] and directly the Device/s itself (e.g.

[ 1 ί) 1 ] , [ 102] .[ 103]) e.g. using its predefined logical interaction interface/protocol [191 ].

The ARTS system is typically comprised of all or any subset of the following subsystems:

( ! ) M2M (Machine-to-Machine) Logical Interaction Subsystem [140] (or named alternatively "Logical Interaction Subsystem" or "LIS" or "Logical Subsystem" or "Logical Interface" or similar combinations). In all descriptions and drawings, "Subsystem" = "S/S", This S/S is responsible for and operates the logical/electrical/software interaction with the device/s. There are several standards and protocols for this logical interaction such as: TR-069 and TR-181 (which defines interaction between CPEs (Customer Premise Equipment, such as DSL/ADSL modem, Cable modem, Router, Set-top box, Laptop, or any device as described above and below that has a logical/electrical/wireless interface) and its server (ACS = Access Control Server) which is located at the sendee operator premise or as part of the Internet cloud (at the World Area Network = W AN), Web interface, of e.g. switches and routers, for monitoring and configuration. Other proprietary non-standard interface/protocol, etc.

(2) M2H (Machine -to-Human) User Interaction Subsystem [ 120] (or named alternatively "User Interaction Subsystem" or "U1S" or "User Subsystem" or "User interface" or similar combinations). This S/S is responsible for and operates the interaction with the user itself in order to get from him/her observations and perform actions required for the puipose of the technical support goal (whether device/s operation or troubleshooting). There are several types of user interactions that may be implemented in the ARTS system, according to several embodiments of this invention: (a) Instant Messaging (IM) application such as Facebook Messenger, Skype, Whatsapp, Telegram, and sim ilar. The user interface may be implemented as a Chat-bot that automatically and autonomously interacts with the user using various artificial intelligence (AI) technologies, (b) Voice interface may be implemented, for example, by using speech-to-text and text-to-speech technologies to convert the needed messages (e.g. of the IM mentioned above) to/from, voice. Optionally this can be also integrated into user personal assistants such as Google Assistant, Amazon Echo, Apple Siri and similar assistants. Further optionally it can also be integrated as a video conference application between the two sides.

(3) Session Manager Subsystem [130] . This S/S is responsible and operates all the logic and methods of the Operation or Troubleshooting process of the session. This S/S comprises a computation engine of the ARTS system and it uses all the interaction subsystems (such as UIS and LIS) in order to achieve the Operation or Troubleshooting process goal.

Typically, at least one interaction S/S is included in the ARTS system. Example S/S internal components and flows, all or any subsets of which may be provided, are elaborated in the following description. Typically troubleshooting refers to handling issues raised by end-users regarding failures of a process or machine/device (or alternatively troubleshooting may also in this document relate to human healthcare diagnostic and curing process), e.g. By logically and systematically searching for a root cause or source of the reported problem or issue, and then solving the issue e.g. By causing the process or (malfunctioning or faulty) machine (or device or human) to become operational/regular/proper again, for the end-user or patient. Typically troubleshooting includes receiving information from an end-user regarding an issue e.g. Malfunction, querying for more information so as to develop a root cause hypothesis, attempting a fix for that hypothesis and if needed doing the same for other hypotheses, until the issue is resolved.

Figure 2 describes an example of an overall scenario in which the ARTS system is deployed and is operating for several embodiments of this invention. In this example, the ARTS system is deployed in External Network [250] which is external to the Local Premise [200] in which the Devices (e.g. [221 ]÷[228]) are located. The ARTS system may be, e.g. deployed as part of the Internet cloud, for example as a service in the Internet and its components/subsystems are deployed in the infrastructure of one of the cloud service providers. In addition to the External Network [250], there is, in this scenario, also the Local Premise [200] where the target device is located (the device that the user needs help to operate or troubleshoot). Local premise may for example comprise or be a customer or end user's house, a vehicle (such as car, van, bus, airplane, ship/boat, autonomous vehicle, etc.), an office, hotel room or temporary location, or any location in which an end-user is located). In Figure 2 several types of example devices are presented:

A . internet modem [221] which may be any type of Internet modem such as

DSL/ADLS/Cable/Satellite modem. In Figure 2 it is a terrestrial modem (e.g. ADSL or Cable modem) that is connected by wireline [290] to the External Network [250] cloud that may be, for example, the Internet. B. Router/Switch (e.g. [222] or [223]) that is part of the network infrastructure of the Local Premise [200]. It may have wire connections/interfaces (such as e.g. [282] or [281]) or wireless connections/interfaces (e.g. Wifi wireless connection [280] and/or [284]) that optionally may be WiFi connections or any standard or non- standards wireless communication connection protocol. C. Wireless user device such as a Laptop (e.g. [224] or [225]) that is typically connected to the Internet (as part of the External Network [250]). Optionally also the user smartphone [2.1 1] may be a wireless device of the Local Premise [200] as it may have, for example, a WiFi wireless connection/interface [284] that is compatible to the wireless network infrastructure on the Local Premise [2.00] and therefore may optionally connect to one of the local wireless routers (e.g. router-B [223]).

D. Wired device, in example a Surveillance Camera or customer lot device

[226] or a Network Printer [227] ,

E. A stand-alone device that does not need to have a communication/network connection (e.g. standalone projector [228] in Figure 2).

There may be several communication connection/interface/route types that may connect entities in the External Network [250] (such as the ARTS system and each of its subsystems) and the device/s located at the Local Premise [200]. There may be a terrestrial wired connection (such as a ADSL of Cable connection, both illustrated as [290]). Alternatively or additionally, there may be a wireless connection (such as a Cellular connection [291] or WiFi connection or Satellite connection). Alternatively there may be a connectioii/interface/routes that may include a chain of several connection types such as wired and thereafter wireless or wireless and thereafter wired (for example from the cloud srver until the end-user house router the connection may be through terrestrial lines and from there it may be wireless to the relevant device (WiFi or Bluetooth or NFC or similar). There may be at least one connection/interface between the ARTS system that is located at the External Network [250] and the entities (including devices) located in the Local Premise [200].

Figure 2 illustrates an example of two connections between the External Network (and its components/entities) [250] and the Local Premise [200] : a wired connection [290] and a wireless cellular connection [291]. There are devices that may support several communication connections/interfaces (whether operated concurrently or alternatively) such as, for example, a cellular smartphone [211] that may have on one hand intra Local Premise connection such as wireless WiFi [284] and on the other hand out of Local Premise connection such as a cellular connection [291] that connects the smartphone [211] to the External Network [250] where the ARTS system [100] is deployed. Each one of the optional devices typically may need to be connected to a sendee or server (e.g. application server [252]) that is located at the Internet (which in Figure 2 maybe part of the External Network [250]). Alternatively or additionally, the device may need to be connected to another device in the Local Premise (such as in several IOT (Internet- Of-Things) use-cases). In case the Human User [210] cannot operate the device, or if the Huma User [210] may encounter a problem, or malfunction (such as no connection to the Internet), it may use the ARTS system [100] for solving the issue.

In addition to the above, there may be several configurations in which the ARTS subsystems may be deployed (separately) between the External Network [250] and the Local Premise [200] for all possible combinations. For example, in another alternative, the Session Manager S/S may be deployed/located at the External Network [250] and the User Interaction S/S and the Logical Interaction S/S may be deployed/located at the Local Premise [200] . Alternatively, in other possibility, all or any subset of the ARTS subsystems may be deployed/located at the Local Premise [200] . The components of the ARTS system that are deployed in the local premise can be deployed for example as part of the software of the device (using the device processors and memory) or as part of a communication device (such as router, smart speaker, switch, etc.) or the end user mobile device (such as smartphone, tablet, laptop, etc.). Alternatively, even part/s of a subsystem (e.g. [120] and/or [130] and/or [140]) may be deployed at the External Network [250] or Local Premise [200].

Optionally and alternatively there may be an architecture where the ART ^' S system, ca be deployed in parallel in the external network and also in the local premise. In this architecture, if there is a connection to the external network then the ARTS system components that are located in the external network are used, but if there is no communication connection to the external network then the ART ^' S system that is deployed locally is used. When a connection from the local premise devices to the external network- is established then the local premise ARTS system is operative to synchronize the external network ARTS system so all or any subset of the data relating to local sessions that were operated is sent to the external network ARTS system.

Figure 3 uses the scenario elaborated in Figure 2 and presents illustrated examples of connection routes (shown as bold dashed lines [310], [311], [320]) between ARTS subsystems and some optional devices located at the Local Premise [200] . These connection routes may be used as part of the session management that is operated by the ARTS system [100]. One example session that is used in Figure 3 is a failure to use the Network Printer [227] by the user Laptop [224], in which the problem or malfunction [350] is in the interface between the Network Printer [227] and Router- A [222]. In order to troubleshoot this issue, several connections must be made by one or more of the Interaction Subsystem and the relevant devices in the Local Premise [200] or External network [250] , One example of such connections are the connections between die LIS [140] and the devices that create the network connection between the Network Printer [227] and the Laptop [224], such as Router-A [222] , Therefore, optionally, a connection route [311] is enabled between the LIS [140] and Router-A [222], so the LIS [140] may, for example, check if the interface of Router-A [222] in the direction of the Laptop [224] is satisfactory (in this example the result is that it is satisfactory). In addition, the LIS [ 140] may also try to check if the interface of Router-A [222] in the direction of the Network Printer [227] is satisfactory, or even the LIS [140] may also try to make (aka establish) a connection route directly to the Printer [227]. In both cases the result will be faulty (not successful) and may hint or indicate the ARTS system [100] where (e.g. which device, including interconnection hardware between devices which may also be regarded as a device) the problem or malfunction exists.

Figure 3 also illustrates a connection route [320] between the UIS [120] and a User Smartphone [211] (which is in this example the User Interaction Device = "UID"). Using this connection route [320], firstly the Human User [210] may initially contact the ARTS system [100] in order to alert the problem or malfunction and to ask for assistance using user interaction software/application (such as described above, e.g. IM application/Chat- bot). Thereafter, the UIS [120] may use this connection route [320] and also the user interaction software in order to help the User [210] to solve the issue, by, for example, instructing him/her [210] to make observations in the Local Premise [200] and its devices or perform actions at the devices in order to solve the issue. Alternatively, for example if the problem or malfunction is detected using the LIS [140], the UIS [120] may initiate the [320] connection route and not the Human User [210] .

In Figure 3b other optional examples of methods and connection routes are presented. In this figure an example of a problem in the application server [252] of a certain service (such as email, video streaming, office applications, storage sendees, music sendee, etc.) is apparent. In this case the user tries to connect to that application sever [252] using Laptop [225] but unfortunately the sendee/connection is faulty (e.g. it cannot get the required sendee or reach the application server) . In this case there are also several connection routes (or communication interfaces/links) that may be activated in order to solve the issue. Optional connection route may be in this case be [310] in which a direct connection route between the LIS [140] and the device which suffers from the problem or ? 3 malfunction (in this case Laptop [225]). The possibility to connect directly the suffering aka . malfunctioning device (from, the same External Network [250] as the application server [252] may indicate to the ARTS system a hypothesis, according to which the problem or malfunction (in general, references herein to "problems" include malfunction/s of device/s) resides in the External Network elements/components [250] (e.g. switched/gateways/routers) or the application server [252] itself. In this scenario, the ARTS system [100] may also use the UTS [120] to confirm or approve the hypothesis by using the UIS [120] to UID (e.g. smartphone [211]) connection route [320b], and so by using die User Interaction Software (UISW) [360b] guide the Human User [210] to observe, e.g. the Router-A [222] or Modem [221] or even Laptop [225] Internet connection status or guide the end-user to perform suitable actions. Further optionally, it may also use connection [320b] in a similar manner of using connection [320] in Figure 3.

The UISW may for example comprise a chat application that is used by ARTS to interact with the end-user, e.g. as shown in Fig. 7. Alternatively or in addition the User Interaction Software may comprise a voice or video application or even augmented reality or virtual reality application configured to present guidelines to the end-user e.g. overlaying the direct picture of a device.

Figure 3c describes another example of a scenario in which only the UIS [120] makes (aka establishes) a connection route in order to handle the issue (whether the issue is a question or difficulty re operating a device or troubleshooting for a problem or malfunction). This case may be relevant, for example, if the LIS [140] cannot be used or the LIS [ 140] cannot make (aka establish) a connection route to the Local Premise [200] . This Fig. 3 c scenario may be used if the LIS has malfunctioned or e.g. when no connection can be established from the LIS to the local premise (e.g. due to a communication problem or to a power problem in the local premise). In this figure there is a connection route [320c] between the UIS [120] and the UID (e.g. smartphone [211]) using a cellular network [260]. In Figure 3c, connection route [320c] may be used similarly to connection route [320b] described in Figure 3b or similarly to connection route [320] described in Figure 3. In addition to this connection route [320c], an example of additional connection route [312] is also illustrated. This connection route [312] uses the terrestrial wired connection [290] between the External Network [250] and the local Premise [200] in order to make (aka establish) a connection between the UID [120] and the UID (e.g. smartphone [211]) and specifically the UISW [360c] in the UID [211] . Each one of the illustrated connection routes, [312] or [320c] may be activated separately or in conjunction with any other connection route. The UIS [120] may choose the optimal connection route in order to contact the UISW [360c] . It may even choose to enable several connection routes concurrently in order to achieve better connection/link reliability and/or throughput (data- rate).

Optionally or alternatively there may be sessions where only LIS can or may be used to solve the problem .

Figure 4 describes another example of a scenario; this time only the LIS [140] makes (aka establishes) a connection route in order to handle the issue (whether difficulty in making a device/s operate or troubleshooting). This case may be relevant, for example, if the UIS [120] cannot be used or the UIS [140] cannot make (aka establish) a connection route to the Local Premise [200] . This figure-4 scenario may be used if the UIS has malfunctioned or e.g. when no connection can be established from the UIS to the local premise (e.g. due to a communication problem or to a power problem in the local premise) or when the end-user is not able to help in the process of troubleshooting e.g. if the end- user is handicapped (e.g. blind) or doesn't have the skill or cognitive ability to perform some or ail observations or actions ) . In this figure, the problem is apparent in the connection between Router-A [222] and Router-B [223], while the User [210] tries to use Laptop [224] and access application server [252] that is located at the External Network [250] , In this example, initially (because e.g., this terrestrial connection is already activated or because it may be less expensive or has higher link performance or more end-user friendly or have better end-user experience) the LIS [140] tries to make (aka establish) a connection with ail the network elements of the Local Premise [200] (or of the External Network) that are part of the estimated connection route between the faulty device and its destination (destination = e.g. application server in the external network) from the direction of the External Network [250] to the faulty device (in this case Laptop [224]) using the wired connection [290] , A successful connection is made to Modem [2210] and Router-A [222], however a valid connection to Router-B [223] from the LIS [140] cannot be made [450] (valid connection may be e.g. when IP packets can arrive to a routing destination/address).

Thereafter, the ARTS system [100] decides to by to reach the not accessed Router- B [223] by using alternative connection route [420] through a different communication interface, namely the cellular network [260] and its Local Premise [200], associated device e.g. the user smartphone [21 1 ] - that may have both cellular connection (to the external network) in addition to, e.g., Wifi connection (in the local premise) that may be used to connect to Router-B [223] . Optionally there may be installed/deployed in the associated device being part of the alternative route (e.g. smartphone [211]) a Local Software [460] e.g. mobile device application or script that implements a bridge or relay for the ARTS LIS [140] and the target device (in this example Router-B [223]), so that LIS [140] may connect by other connection route to the device and better handle the issue where typically the issue comprises a need for help/support regarding device operation, or troubleshooting for a problem, or malfunction.

Figure 5 has a similar problem scenario as Figure 4, and also in Figure 5 the terrestrial connection route cannot reach Router-B [223] , However, in Figure 5 there is an alternative implementation to the connection route [420] of Figure 4. In Figure 5 a connection route in made from the LIS [140] and local premise associated device (also herein smartphone [21 1]), however the smartphone (software) includes, e.g. instead of a bridge or relay, a dedicated software [560] that has full or part of the functionality of the ARTS system [100], If the full ARTS system is aboard the device (e.g. smartphone [21 1]), then the External Network ARTS system [100] may not be used or may be partially used. A typical example of ARTS partitioning in this scenario may be that the LIS may be implemented within the local software [560] whereas the other subsystems of the ARTS system [100] may be used at the External Network [250] (e.g. the session manager S/S [130] may be deployed in the external network and operate the local LIS. In this case the external network LIS [140] is typically an empty component that is serving as a relay from the local LIS that is part of the local software [560] and the session manager [130]). This may enable the possibility to use this alternative route (in addition to route [510]) also when the two different communication connections of the associated device (e.g. smartphone [211]), the cellular and the WiFi connections, cannot operate simultaneously but rather in series (as sometimes smartphones cannot operate regular WiFi connection and in parallel cellular link in data mode) or when this scenario of local ARTS components (e.g. as part of the local software [560]) enables better performance (for example accurate observations to the devices in the connection route between the faulty device and its destination or quicker response) or when there is no connection route that may be established so a local (in the Local Premise [200]) ARTS system (e.g. as part of the local software [560]) may be the only system that may be used to solve the issue. It may be highlighted that the local software can be installed also on any device in the local premise.

Figure 9 presents an example of a flow diagram of a troubleshooting session from beginning [910] to its end (e.g. either [917] or [918]). Each presented component, here and in other diagrams herein, may be present or absent, depending on the embodiment, use- ease, application-specific design considerations and so forth.

Typically, chat flow is presented in bold, whereas remote PPI

observations/actions are presented in dashed line. Session interactions block 915, typically including elements of both, is presented both in bold and in a dashed line.

The session may begin by a contact from the customer (experiencing technical problem) [910] or by detection of a problem by the ARTS system. Thereafter, an optional authentication process is carried out [91 1 ] in order to authenticate the end user. An additional optional process may then be executed in order to validate the location (premise) of the TS (troubleshooting) session. Using the authentication and validation data, the ARTS system may load [920] additional information needed for the TS (troubleshooting) session from the database [930], e.g. from a CRM/ERP/SAP database with which the system herein has a data link. Moreover, using this data, a remote PPI (product provisioning interface = M2M logical interaction interface) process may also optionally be carried out in order to get needed data from the devices of the scenario (e.g. devices that are part of the estimated or conjectured connection route between the estimated faulty device and its destination).

After all or any subset of the operations mentioned above have been performed, the first question of the TS session is presented to the user [913] . This may be a directed question (in which several options are shown to the user), or an open question (the user writes in his/her own words) and the user response is received and processed to begin the iteration phase of the session [915]+[9!6] , In the iteration phase, in any iteration an action is carried out by the ARTS system, either M2H or M2M or both, and a response (either from the user or the machine or from both) is received and processed. If the algorithm concludes that the session is ended, it activates the session tennination process (operations [917], [918], [919]), otherwise it continues to choose and execute the next action of the ARTS system. If termination of the session has been concluded, then there may be several options e.g. some or all of:

* if a successful resolution of the problem has been concluded, then the ARTS ask the user if the problem is resolved. If yes, then it may also ask the user if s/he wants in any case to talk with a human agent and acts accordingly [918] or [919] ,

* If the problem type is detected but cannot be resolved remotely, then the ARTS explains that to the user and asks him/her to continue to solve the ΊΊ issue (e.g. if a device is needed to be replaced, it may direct the user to a Chat-bot that will arrange a visit of a technician or deliver}' of a new device, or alternatively to direct the user to human agent to complete the case ticket) . * If no known problem is detected, then the ARTS will explain to the user that it did not succeed to detect a known problem, and will suggest that the user be directed to a human agent to continue the handling [917] .

Figure 6 presents an example of a detailed block diagram of internal blocks and flow of part of the Session Manager subsystem [130] and the M2H User Interaction subsystem [120], which may be implemented as an elaboration of the iteration process presented in Figure 9 as [915] and [916] . The iteration phase begins Next Action Selector (NAS) from the response to the first question [610], The user response is typically fed to the processor implementing [631] that is operative to analyze this data, and its computation results may include for example the action type (e.g. M2H or M2M or both) and/or the action root (e.g. for M2H action, the "root" to the sentence/question that will be presented to the user) and/or the action metadata (e.g. all or any subset of: consistency/inconsistency of last responses, impatience of the user, change of some past data, etc.). In order to compute the next action by the NAS [631] the NAS [63 l j) optionally uses the current World Model information by interacting with the World Model Handier [632] .and by optionally using all past sessions database (that includes also the current session previous data/ operations/actions and responses). The World Model Handler [632] stores the current World Model for the current session in computer memory. The World Model typically comprises a computer-stored representation of a model of the connection route elements/devices and the communication network structure/topology (e.g. by a combination of probabilistic model and/or logical model and/or neural network model and/or any type of software and/or algorithmic model). An example of part (for simplicity) of a World Model of a device that is part of the World Model is illustrated in Figure-8. Then the result of the NAS [631] is processed by the Action Type selector [634] . If the action is Session End, then termination of session process may be activated (e.g. according to what was described in Figure 9). Alternatively, if M2M action is chosen [192], then this action may be transferred to the M2M Logical Interaction System [140] for further execution. If M2H user action is chosen [193] then the example of internal process of the M2H User Interaction S/S [120] is presented also in this figure, e.g. as elaborated in the following paragraph. The NAS M2H action is then typically processed by the Next Message Generator (NMG) [610] that comprises logic which, when used to configure a suitable processor, is operative for generating/formulating the sentence that will next be presented to the user in the session. The message may be in example directed message (with several responses to choose from) or message with open response (where the user writes his/her own words in the response). The message may be a question or may be (prompting for) an action (e.g. pressing a button, observing the color of a LED light, etc.) to be done by the user. In order to formulate the next message, the NMG [610] typically uses the abovementioned information provided by the NAS (e.g. root, metadata). First NMG [610] may use the root of the message in order to build a main part of the message, e.g. by using the Root to Sentence/s Database [61 1], The Root to Sentence/s Database [611] may be implemented using any suitable technology, e.g. as a table that converts the root to predefined sentence or by more complex root to sentence function that uses NLP (Natural Language Processing) techniques to make the message. Alternatively or in addition, the NMG [6 ! 0] may use the Sentences Additions Database [612] in order to add to the baseline message made by the Root to Sentence/s Database [611] . The Sentences Additions Database [612] typically uses the metadata given by the N AS [631 ] in order to add, e.g. a prefix or suffix to the message that resemble or are suited to, e.g. using predetermined rules, the information encapsulated in the metadata. These additions may for example add emotions, surprises and/or inconsistency statements to the baseline message (examples will be shown in Fig. 7). If a directed message is chosen, then the NMG [610] also may use the Answers Database [613] in order to choose the answers that will be presented to the user as part of the next message. Optionally the NMG [610] may also add media to the message by using the Media Additions Database [614], as a result of action root or metadata. Media addition types may include all or any subset of pictures, video, audio, AR (augmented reality) data, etc.). For example, if the metadata includes information that the user is unconfident or inconsistent, then it may choose to add more informative media to the message, to further clarify the message.

The overall message is then typically transferred to the Sessions database (the user interface part of it [615]) for storing/logging and also typically to the Presentation Function [616] that presents the message to the user in his/her preferred channel (e.g. Facebook, WhatsAPP, Telegram, Skype, SMS MMS, email, IVR/voice system, etc.). The preferred channel may be known in advance e.g. pre-siored or may be learned from previous sessions with the end-user, in example the channel that was used to make the initial connection with the ARTS system (such as block [910] in figure-9) or a channel that the end-user has chosen in advance. Thereafter, a response from the user is received [617] . The response is stored [680] in the Sessions Database and further processed by the Answer Type selector [618] . If the user chose one of the directed answers [621 ] then that directed answer is transferred to a suitably configured processor, the World Model Handler [632] and updates its parameters so that the processor configured as an AS [631] may use it (aka the World Model) for the next iteration computation. If no answer is given for a defined time interval than the NAS [631] may continue to perform an additional action for the next operation. If an open answer is given [622] then the open answer may be transferred to the Answer Analyzer function [623] that may, utilizing a suitably programmed processor, analyze the open answer and may transfer the result to the World Model Handler [632] and may update the World Model's parameters so that the NAS [631] may use the World Model for the next iteration computation. For example, the Answer Analyzer may use NLP techniques to map the open answer to one of the predefined directed answers, for example synonyms may be mapped to the similar directed dialog answer (e.g. directed answer "Yes" may have open answers like "Yep" "Sure" Of course" etc.).

In Fig. 6, the root (of a sentence) may include an observation generator (e.g. a name of observation parameter that may be asked to be observed as part of the session, such as LED light color or status, cable connection validity, icon status in the laptop, etc.). Metadata may include data determining which additions to add (sentence additions may include prefix, suffix, emojy, etc.) including data such as emotions e.g. surprise, or inconsistency in the response of the end-user in the UIS interface.

Fig. 7 presents an example of part of a chat session [700] which is part of the automated remote troubleshooting session that is described e.g. in Figure 6, In the upper part, a directed answer part of a message is presented [710] . It may be seen that there are three answers that are presented for the user to choose from ("LED is Qn"/"LED is Off '/"Don't Know") that were generated by the NMG [610] using the Answers Database [613]. The user then chose (e.g. pressed the touchscreen) the "LED is On" answer [720], As described in last figure description, this answer updates the World Model Handler [632] and the NAS [631] then chooses a next action. The action was also M2H type and a root and metadata were sent to the NMG [610] . In this example, from the metadata a prefix was chosen [732] that hints to the user that it wants more assurance regarding information that was already given ("Double checking... "), and the rest of the message is generated from the action root [730] - which is a question regarding the LED light status/color. The message also includes media [740] (a picture of the router including an arrow to highlight the position of the LED) as described in Figure 6 and also directed answers [750] , Now a response from the user is expected. In the window also an open answer section [760] is presented, where the user may write his/her open answer, if desired.

Fig. 8 illustrates an example of a small basic probabilistic graphical model of electronic de vice [800], including Conditional Probability Table(CPT) [853] of one of its nodes [833] . This model is processed by the World Model Handier ([632] in Figure 6) and represents the current probabilistic information regarding the device (which is pari of the overall World Model) at each iteration or iteration step. The NAS [631] uses the World Model to best choose next action. It may use any type of model (e.g. Propositional logic, higher-order logic, PGM (Probabilistic graphical model, which may be directed or undirected), neural network, deep neural network, genetic algorithm, etc.) and appropriate method for doing this e.g. information/entropy based computation, inference based computation, any search method (e.g. classical, complex) and using any learning technique in order to better perform in future sessions (e.g. using supervised or/and unsupervised and/or reinforcement learning techniques).

Each one of the connection routes described above may be implemented/enabled/operated in parallel to any other connection route. Similarly, each one of the user interaction softwares (UTSWs) described above may be implemented/enabled/operated in parallel to any other user interaction software (UISW).

A system may be provided according to any of the preceding embodiments wherein the ARTS system or any or some of its components (for all its various implementation/configuration alternatives) establishes a link to all relevant destinations. Destinations may be all estimated components/elements that are part of a communication route, between the estimated device that is faulty or device currently hypothesized to be faulty, and the faulty device destination.

According to certain embodiments, the session manager subsystem aka s/s controls the lis and uis and is configured for managing the session with the human and/or devices in the human's environment, be they malfunctioning devices, devices suspect of malfunctioning, or devices helpful in resolving the malfunctioning e.g. by sensing relevant local parameters, an example of a helpful device is a cellphone, preferably having downloaded thereupon an app configured to interact with the system shown and described herein, the cellphone can he used by a human entity to image a malfunctioning or suspected malfunctioning device, the human may be instructed by the m2h re how and when to image the device

The session manager subsystem also typically has a suitable data interface or api with at least one external database e.g. one or more dataset/s generated by one or more existing technical support provider/s, each storing data regarding end users requiring technical support and their devices, alternatively or in addition the session manager subsystem (and/or oilier subsystem/s) may have access to and/or may generate or update in the course of its operation, its own dataset, typically set of relational databases, storing data regarding end users requiring technical support and their devices, dataset/s may include tables or other digital representations storing and maintaining/updating data e.g. any or all of the databases shown in fig. 6 and/or any tables or other digital representations storing data regarding all or any subset of:

a. each of many models of appliance, for example, an appliance-model table may have a record pertaining to an HP workstation model number such-and-such which stores, say, whether or not the appliance includes a processor and perhaps which processor, whether or not the appliance includes an output device such as a display screen, the type of appliance (printer/scanner as opposed to washing machine or lawnmower), an ontology with natural language descriptions of common problems, such as "paper doesn't go in" or "paper feed is broken" which may both be associated with a single meaning (a single malfunction), and contact information of entities which respectively provide, for each of several regions, service technicians for malfunctions which cannot be resolved remotely. b. each of many end-users, for example, an end-user table may have a record pertaining to an end-user called Joe, including his cellphone number and address, with pointers to the 18 (say) known applicance -model types that Joe owns, which may include, say, Nokia cellphone model number such-and-such, HP workstation model number such- and-such, Amana refrigerator model number such-and-such, and electric lawnmower whose manufacturer and model number are such-and-such, for each such, the table may store the serial number of the device, its date of purchase, whether or not it is eligible for warranty and with which technical support provider, and so forth, the table may also store derived score/s or grade/s regarding Joe's level of technical knowledge or skill as experienced in the past by the system , for example, if Joe responded "I don't know" in past sessions between the system herein and Joe, more frequently than most end-users, Joe may be assigned a score or grade which corresponds to a relatively low level of technical knowledge, and/or, the system herein may present end-users with menus of possible malfunctions for a given device (such as "paper feed broken", "no power", "scanner does not work" and so forth), and ask the end-user to pick the malfunction he is experiencing, if joe has in die past failed to properly identify the malfunction, more than other end-users, Joe may be assigned a low score or grade than they, ail other things being equal, if joe has in past sessions frequently, relative to population norms, required a service visit and only infrequently or never succeeded in resolving the malfunction remotely, joe may again be assigned a low score or grade, relative to others who resolved remotely more frequently, it is appreciated that any suitable criteria may be employed to evaluate Joe's level of technical knowledge or skill, the above criteria being merely exemplar)', also, any suitable combination of the criteria may be employed; for example, a weighted sum of joe's score or grade for various criteria e.g. some or all of the above criteria may be computed; any suitable technique may be used to determine weights e.g. using machine learning or neural networks

If end-user Joe calls in to request service for a microwave which is not one of his known devices, any data regarding the microwave collected during the session with Joe may be stored in association with Joe's record in the end-user table.

Relationships between end-users and devices may be learned using automatic technologies such as those described in patent document US20120311074A1 2012-12-06 entitled Methods for Displaying Content on a Second Device that is Related to the Content Playing on a First Device, or in patent document US20150215668.

C. Each of various technical support provider/s, e.g., for each, its contact information for end-users, IP address of its internet presence, data link to the system herein if any, and data identifying the device types, devices and/or end-users supported thereby.

It is appreciated that the system is advantageous because its architecture is modular in the sense that the system e.g. A b2c system, in order to function as a unified support center, may have different levels of cooperation with different technical support provider/s. for example, the system may enjoy a data link to the server and/or datasets of certain technical support provider/s such as, say, Cellcom and Toyota, (e.g. via the provider's online Customer Relationship Management (CRM) software), but not to others. however, the system may store contact information for the technical support provider/s in the latter category, such that the system supports all devices owned by end- users, to at least a minimum extent, specifically, the system provides fully supported Remote Troubleshooting for devices associated with certain technical support provider/s which cooperate with (have a data link to) the system herein, provides end users only- contact information to other technical support provider/s (eg. using a table storing pre- stored contact information such as telephone and/or link to internet presence, for non- cooperating technical service providers) and provides other end users only with generic information regarding certain malfunctioning devices, for example, if a user says "my Amana refrigerator broke" and Am ana is not associated with any technical service provider known by the system, the system may simply direct that end-user to her or his search engine or human or automated telephone directory services or may simply provide contact information e.g. a telephone number of a human professional (computer technician, refrigerator or washing machine technician, electrician, plumber, etc.), e.g. from a list of professionals in the end-user's geographical area or a professional previously consulted by the end-user whose profession and contact information have been stored.

d. data regarding technical support sessions, for example, data regarding a technical support session may include the sequence of messages sent back and forth between the end-user and the system, links to the end-user and to the faulty device, and so forth, it is appreciated that machine -learning may be applied continuously or periodically to the session data to refine the system's functioning, for example, sessions may be analyzed continuously or periodically, using machine learning, to determine the absolute or conditional probabilities of various malfunctions, for a given type of or set of devices, and the system may then be re-configured to query about more common malfunctions first, conditional probabilities may be conditioned on any suitable variable stored by the system; for example, it may be the case that certain malfunctions are more common for certain end- user profiles, or certain times of day, or certain times of year, or for devices of a certain age ("young" as opposed to "old" devices), or certain geographical areas, this enables the system to upgrade its functioning. For example, connectivity issue may be reported by an end-user, in which case, using machine -learning or other big data analysis techniques, the system may accumulate knowledge suggesting high conditionai probability, in certain regions or weather conditions, that an Ethernet cable could be damaged or unplugged (Layer 1 issue), and low conditional probability in other conditions, and similarly, other conditions which are associated with high or low conditionai probability that the issue might be caused by- network requests not going through (Layer 3), or by an application not being properly- coded (Layer 6 issue), then, the high probability hypotheses may be tried before low probability hypotheses, given a specific end user under specific known conditions. Devices can also include household appliances and anything else, including but not limited to physical equipment, that breaks or malfunctions and causes people to need help in fixing the problem by contacting a troubleshooting agent.

a "device" might even include a person who is medically malfunctioning, a device may or may not form part of an "internet of things", may or may not include a processor, may or may not include a data input option e.g. keypad or interface to a remote control device; and may or may not include a data output option e.g. indicator/s such as lights/LEDs, a display screen or loudspeaker and speech generator.

Typically (say in the embodiment of Fig. 9) all or any subset of the following operations may be performed, suitably ordered e.g. as shown:

10. open session responsive to receipt of a trigger alia session-opening contact e.g. from customer aka end-user, e.g. using chat or voicemail or text message or email (or from, "internet of things" device with predictive maintenance functionality which is capable of independently issuing a malfunction warning about itself or another device in its vicinity)

20. hypothesize which device/s is/are malfunctioning

30. determine which communication route/s to open, and open e.g. using device- or human- communication logic, may include using accumulated knowledge regarding devices in this home or premises, to identify devices other than that identified by the end user, which might actually be causing the problem, or to identify devices which may be used to help diagnose the problem e.g. a router may help diagnose a connectivity problem experienced by another device.

40. in parallel or in series, hypothesize as to root cause of malfunction, check hypotheses, fix, if fix does not work return to previous step/s, e.g. using troubleshooting logic.

It is appreciated that the (ARTS) server may maintain database/s, accumulating data from sessions and using that data for future sessions, where the data may include all or any subset of the following:

- Time of observations and events e.g. malfunction reports via chat, measurements arriving from devices - type and model and age and history (past malfunctions) and other characteristics, of each encountered device

- Device configuration (device parameters and their values)

- Detected problem (if detected), problem classification (user mistake, user hardware/device failure, external infrastructure failure, etc.)

- User interaction log (the chat between server's virtual agent (VA) and the human user), including the questions/actions the V A ask the user and the user answers.

- VA internal parameters during the session (i.e. the probability of each potential problem during the session, the estimated technical user skill during the session, the estimated patience of the user during the session, etc.)

- Local premise data such as devices' types and models, network architecture and topology, house structure and physical location of each device

- External infrastructure data relevant to (e.g. connected to) the user/local premise, such as external network routing, and devices in this route.

- level of User's technical skill and extent of user's patience (deduced during interactions or sessions with him/her)

To estimate patience, contextual mining of text and/or natural language processing and/or Sentiment Analysis which uses acoustic characteristics of a speaker's voice and/or context of the conversation to identify agitation and other negative sentiments, may be employed. The db may store a user's average level of (say) agitation, or the duration that elapses from the beginning of the session, on average, before this sentiment is first identified, for this user, or a user's tendency to terminate the session without resolving the fault, and how long (duration) after the beginning of the sessions this occurred, and so forth. The duration may be mentioned in time, or in number of queries (or weighted score taking into account complexity of queries for the end-user) that accumulated before the user became agitated, terminated past sessions, and so forth. Central tendencies other than averaging may be employed such as median or mode. According io certain embodiments, data is provided to the (ARTS) server by existing crm databases to which the the (ARTS) server may have data access e.g. via a suitable APT or channel. These crm db's may belong, say, to cooperating household appliance maintenance centers of , say, respective appliance manufacturers and operative to store customer data (e.g. Technical, billing, marketing) from ail interactions/ sessions of the crm with her or him. Example crm-stored parameters that may be useful for the (ARTS) server might be the caller's street address, such as 15 west street, apartment 8, the caller/end-user/customer name, address, age, profession, what he likes, her or his Local premise data such as de vices' types and models, network architecture and topology, house structure and physical location of each device, External infrastructure data relevant to (e.g. Connected to) the user/local premise, such as external network routing, and devices in this route.

Example crm-stored parameters that may be useful also include Historical data of monitoring and command from each of the user devices or external network elements relevant to the user. This data may, say, include the status of the device (active or off), device parameters' configuration (e.g., in home router, SNR aka signal to noise ratio in each of its links, the BER aka bit error rate of each link, the WIFI cniiguration

e.g. Channel number, the DNS config, the WAN connection type ( pop, DSL, S ATCOM, GPO /optical, Cellular, etc.). Is WIFI enabled/disabled, etc. Example crm-stored parameters that may be useful also include Historical data of interaction with the user, e.g. Past voice calls, chats, etc.

More generally, any data that the (ARTS) server stores, may be provided by cooperating crm db's, and vice versa, any data provided by cooperating crm. db's may be stored and/or used on the fly, by the (ARTS) server.

Any suitable method may be employed, to establi sh and employ communication route/s between the (ARTS) server shown and described herein, and between device/s that the server decided to communicate with e.g. a faulty device (one that has been reported by an end-user to be faulty) or a device, useful for diagnosis (e.g. a router which is useful for diagnosis of network problems) on the same premises or in the same vicinity as the faulty device, for example, all or any subset of the following operations 1 - 5 may be performed, in any suitable order e.g. as follows: 1. dentifying location of problem (aka "local premise" of end-user associated with a faulty device) and preferably the problematic device, e.g. by consulting a stored record in DB (database) and/or based on a GPS location of the user (which may, say, be obtained from the user's smartphone or other GPS-localizable device) and/or by asking him/her e.g. using chat.

2. computing, in the (ARTS) server, one or more possible/optional connection routes between the end-user's device that has the problem and its destination ("user-destination routes"), the server may maintain and access, for this purpose, a DB of networks storing all known (e.g. accumulated from previous sessions) topology, routing entities, all devices m the local premise or communicating with an external network connected to the local premise, etc.)

3. computing ail possible routes between (ARTS) server and each of the nodes (e.g.

gateways, routers, repeaters, relays, switches, application servers, the end-user device itself, etc.) in the user-destination routes ("diagnostic routes")

4. establishing diagnostic routes and generating diagnostic for nodes of the user- destination routes. May use data from the DB/s referred to above in order to optimize this search e.g. using machine learning - ML), for example, if a given problem, was more common than other problems in the past (e.g. is observed in the DB to be more common) the server may prioritize the search order of nodes accordingly, prioritizing nodes associated with common problems over nodes associated with rare problems, to be more time efficient,

5. Storing to the DB all diagnostic data for future use (ML)

Referring to the embodiment of Fig. 4, in an example, operations 1 - 3 of the above process may be as follows:

1. Identifying location of problem (aka "local premise" [200] of end-user associated with a faulty device) and preferably the problematic device [223], e.g. by consulting a stored record in DB (database) (part of [100]) and/or based on a GPS location of the user (which may, say, be obtained from the user's smartphone [211] or other GPS-localizable device) and/or by asking him/her e.g. using chat (by using an application in the smartphone [211])

2. computing, in the (ARTS) server [100], one or more possible/optional connection routes (i.e. [410] and/or [420]) between the end-user's possible/estimated faulty device (or devices) that has the problem [223] and the faulty device's destination [252], termed "user-destination routes" e.g. user-destination route (A) including edges [282]+[281]+[290]+[edge connecting gateway 25 land application server 252 e.g. as in figure-3c] , user-destination route (B) including edges [284]+[291]+[edge connecting cellular network 260 and external network 250 e.g. as in figure-2] . the server may maintain and access, for this purpose, a DB of networks storing all known (e.g. accumulated from previous sessions) topology, routing entities, all devices in the local premise or communicating with an external network connected to the local premise, etc.)

3. computing all possible routes between (ARTS) server [100] and each of the nodes (e.g. gateways, routers, repeaters, relays, switches, application servers, the end-user device itself, etc.) in the user-destination routes ("diagnostic routes"). For the above user- destination routes A and B these diagnostic routes may be:

for user-destination route "A" the diagnostic routes may be routes between the ATRS server [100] and the following nodes:

(i) Router-B [223]

(ii) Router-A [222]

(iii) Modem [221]

(iv) Gateway [251]

(v) application server [252]

for user-destination route "B" the diagnostic routes may be routes between the ATRS server [100] and the following nodes:

(i) Router-B [223]

(ii) User smartphone [211] (iii) Elements forming part of e.g. being nodes of Cellular network [260] that are in the route between the user smartphone and the external network.

(iv) Elements forming part of e.g. being nodes of External network [250 ] that are in the route between the cellular network [260] and the application server [252].

(v) application server [252]

It is appreciated that the system shown and described herein may, technically speaking, be implemented in one or many of various forms, for example, end users seeking support for their faulty devices may access the system via a website or via a cell app or via a typically open-source voice operated personal assistant such as Apple Siri, Google Now, Lucida or Sirius, e.g. by pressing a virtual "technical support" button or saying a simple one-phrase-covers-all activation phrase such as "Alexa, this isn't working", "Alexa, fix this" or via chat, responsive to the end-user's initial call for help, the system may have an initial general response capable of eliciting data from many or all users, such as "take a picture of whatever is not working and send it in", or "what's not working?", and/or the system may determine the end-user's location within his home using any conventional localizing technology, then may compare this location with known or deduced locations of the user's known devices in order to hypothesize re which device may not b working.

A particular advantage of embodiments herein is enhanced usage of equipment by even uninitiated end-users, due to the architecture and configurations shown and described herein, in many cases, in which the malfunction is simple and/or known and/or in which the user has a high enough level of skill to provide good diagnostics to the system, over a communication route, the equipment's ability to serve the end-user will be restored much faster than would be the case, if a human serviceman would need to be coordinated and physically arrive, and even faster than would be the case if the remote system had only a human channel (as in a call center) or only a channel for device-generated data.

Another advantage is in identification of malfunctioning whose origin (which device is faulty) is not known, for example, a user may report that "there's a smell of burning", and the architecture of the system enables the system, to effectively troubleshoot even though it is not known to the end user, which device is harboring the root cause of the issue. Or, a user may report that an individual router or device served thereby is not working, but the system knows from consulting its device database for devices associated with this user, that the user also owns another router and/or repeater/s which could be hypothesized to be causing the issue attributed, perhaps wrongly, by the user, to the individual router or device served thereby.

It is appreciated that terminology such as "mandator} _' ", "required", "need" and "must" refer to implementation choices made within the context of a particular implementation or application described herewithin for clarity and are not intended to be limiting since in an alternative implementation, the same elements might be defined as not mandatory and not required or might even be eliminated altogether.

Components described herein as software may, alternatively, be implemented wholly or partly in hardware and/or firmware, if desired, using conventional techniques, and vice-versa. Each module or component or processor may be centralized in a single physical location or physical device or distributed over several physical locations or physical devices.

Included in the scope of the present disclosure, inter alia, are electromagnetic signals in accordance with the description herein. These may cam' computer-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order including simultaneous performance of suitable groups of operations as appropriate; machine-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order; program storage devices readable by machine, tangibly embodying a program of instructions executable by the machine to perform any or all of the operations of any of the methods shown and described herein, in any suitable order i.e. not necessarily as shown, including performing various operations in parallel or concurrently rather than sequentially as shown; a computer program product comprising a computer useable medium having computer readable program code, such as executable code, having embodied therein, and/or including computer readable program code for performing, any or all of the operations of any of the methods shown and described herein, in any suitable order; any technical effects brought about by any or all of the operations of any of the methods shown and described herein, when performed in any suitable order; any suitable apparatus or device or combination of such, programmed to perform, alone or in combination, any or all of the operations of any of the methods shown and described herein, in any suitable order; electronic devices each including at least one processor and/or cooperating input device and/or output device and operative to perform e.g. in software any operations shown and described herein: information storage devices or physical records, such as disks or hard drives, causing at least one computer or other device to be configured so as to carr ' out any or all of the operations of any of the methods shown and described herein, in any suitable order; at least one program pre-stored e.g. in memory or on an information network such as the Internet, before or after being downloaded, which embodies any or all of the operations of any of the methods shown and described herein, in any suitable order, and the method of uploading or downloading such, and a system including server/s and/or client/s for using such; at least one processor configured to perform any combination of the described operations or to execute any combination of the described modules; and hardware which performs any or all of the operations of any of the methods shown and described herein, in any suitable order, either alone or in conjunction with software. Any computer-readable or machine-readable media described herein is intended to include non- transitory computer- or machine-readable media.

Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any operation or functionality described herein may be wholly or partially computer-implemented e.g. by one or more processors. The invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally include at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.

The system may, if desired, be implemented as a web-based system employing software, computers, routers and telecommunications equipment as appropriate.

Any suitable deployment may be employed to provide functionalities e.g. software functionalities shown and described herein. For example, a server may store certain applications, for download to clients, which are executed at the client side, the server side serving only as a storehouse. Some or all functionalities e.g. software functionalities shown and described herein may be deployed in a cloud environment. Clients e.g. mobile communication devices, such as smartphones, may be operative!}' associated with, but external to the cloud.

The scope of the present invention is not limited to structures and functions specifically described herein and is also intended to include devices which have the capacity to yield a structure, or perform a function, described herein, such that even though users of the device may not use the capacity, they are, if they so desire, able to modify the device to obtain the structure or function.

Any "if -then ^" logic described herein is intended to include embodiments in which a processor is programmed to repeatedly determine whether condition x, which is sometimes true and sometimes false, is currently true or false and to perform y each time x is determined to be true, thereby to yield a processor which performs y at least once, typically on an '"if and only if basis e.g. triggered only by determinations that x is true and never by determinations that x is false.

Features of the present invention, including operations, which are described in the context of separate embodiments may also be provided in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding process embodiment and vice versa. Also, each system embodiment is intended to include a server-centered "view" or client centered "view", or "view-" from any other node of the system, of the entire functionality of the system, computer-readable medium, apparatus, including only those functionalities performed at that server or client or node. Features may also be combined with features known in the art and particularly although not limited to those described in the Background section or in publications mentioned therein.

Conversely, features of the invention, including operations, which are described for brevity in the context of a single embodiment or in a certain order, may be provided separately or in any suitable subcombination, including with features known in the art (particularly although not limited to those described in the Background section or in publications mentioned therein) or in a different order, "e.g." is used herein in the sense of a specific example which is not intended to be limiting. Each method may comprise some or all of the operations illustrated or described, suitably ordered e.g. as illustrated or described herein.

Devices, apparatus or systems shown coupled in any of the drawings may in fact be integrated into a single platform in certain embodiments or may be coupled via any appropriate wired or wireless coupling such as but not limited to optical fiber, Ethernet, Wireless LAN, HomePNA, power line communication, cell phone. Smart Phone (e.g. iPhone), Tablet, Laptop, PDA, Blackberry GPRS, Satellite including GPS, or other mobile delive }'. It is appreciated that in the description and drawings shown and described herein, functionalities described or illustrated as systems and sub-units thereof can also be provided as methods and operations therewithin, and functionalities described or illustrated as methods and operations therewithin can also be provided as systems and sub-units thereof. The scale used to illustrate various elements in the drawings is merely exemplary and/or appropriate for clarity of presentation and is not intended to be limiting.