GB2620913A

GB2620913A - Asynchronous communication system

Info

Publication number: GB2620913A
Application number: GB2210546.4A
Authority: GB
Inventors: Mani Subramaniam
Original assignee: Csharp Solutions Ltd
Current assignee: Csharp Solutions Ltd
Priority date: 2022-07-19
Filing date: 2022-07-19
Publication date: 2024-01-31
Also published as: GB202210546D0

Abstract

Typically, users use online booking services to book an appointment which requires internet access. The invention provides an appointment booking system that allows a user to submit appointment requests (e.g. for a doctors surgery) in an asynchronous manner (i.e. not “live/realtime”) using SMS messages, email, a phone call or the like. This allows users to make use of automated booking systems without requiring a smartphone, computer or access to the internet. The system implements a cloud-based command processing platform and an application programming interface (API). Upon receiving a command to perform a function at the API associated with a third party, such as booking an appointment at a medical facility, it is stored in a cloud-based intelligent storage means. Each time a command is received, a new sequence of processes is initiated. Each command is acted upon separately and asynchronously, enabling a large number of commands to be processed simultaneously at any given time. The resources used to process the commands are only used as and when they are required. For example, a user could send a text message to the third-party API with the command “BOOK Earliest {From ‘date’ To ‘date’}”, to request the earliest appointment.

Description

Asynchronous Communication System

Technical Field

The present invention relates to a method and system for providing asynchronous communication between at least two entities in order to provide services such as booking services on a large scale.

Background to the Invention and Prior Art

Medical facilities, and other service based organisations, often provide online booking services to allow their users to make appointments or request services via a computing device. In such systems, these services are accessed synchronously, which means that a patient typically "logs in" to one of these applications (for example, on a desktop computer, personal computing device or smart phone) and then accesses the required booking services then and there. For example, if a patient intends to book an appointment at a doctor surgery, they may login to an application on their mobile phone, check for available appointments, and then book a slot that works for them. Once they are done, they will then log-out of the third party application.

However, for the patient to access these booking services, the patient must necessarily have access to the internet, which may not necessarily be the case for all patients. Additionally, the patient only has "synchronous" access to these services. This means that, when booking an appointment, the patient cannot do much in the case where there are no appointments available at the instant that they are looking for available slots. This will often result in users continuously "refreshing" the page in the hope that appointment slots may open up. This wastes not only the patients' time but also put needless stress on all the systems (e.g., servers, CPUs, etc.) used to implement the booking service.

As such, there is a need to provide an improved method and system for providing booking 25 services.

Summary of the Invention

Embodiments of the present invention address the above noted problems by providing a method and system for providing asynchronous communication between at least two entities, for example, a patient and a clinical service provider. To do this, the system implements a command processing platform comprising a set of instructions configured to be run whenever a command is received. As such, minimal resources (e.g., central processing unit (CPU), memory, etc.) are being used when there are no commands to be processed. On receipt of a command, it is stored in a cloud-based intelligent storage means. Each time a command is received at the cloud-based intelligent storage means, a new sequence of processes is initiated in order to act on the command. In doing so, each command is acted upon separately and asynchronously, enabling a large number of commands to be processed simultaneously at any given time. Additionally, the cloud-based intelligent storage means will keep a record of what processes have been completed and the associated data, and will send this information to other resources if those currently working on a command fails in any way.

A first aspect of the present invention provides a method of asynchronous communication, the method comprising receiving, at a command processing platform, a first command from a first client device to perform a first function at a first application programming interface, inputting the first command to a first cloud based intelligent storage means, outputting, from the first cloud based intelligent storage means to a first orchestrator server, a request to initiate a first sequence of processes in response to the first command, wherein the first sequence of processes comprises a plurality of instructions for carrying out the first command, executing, at the first orchestrator server, the first sequence of processes, wherein the executing at least comprises communicating with the first application programming interface, and outputting a result of the first sequence of processes to the first client device.

As such, upon receiving a command to perform a function at an application programming interface (API) associated with a third party, such as booking an appointment at a medical facility, the command (including any associated data and/or criteria) is input to an intelligent storage means. For each command that is received, the intelligent storage means will instruct a server to initiate a new workflow of tasks needed to execute the command, the server being configured to process and complete the workflow as a sequence of processes within a single location. As such, rather than queuing and polling the received commands, they are processed separately and independently (i.e., asynchronously), the resources used to process the commands only being used as and when they are required. In doing so, large quantities of commands may be processed in parallel, with minimal resources being used when there are no commands to be processed. In the respect, the command processing platform can receive a plurality of commands, each command being processed as described above.

Communicating with the first application programming interface may comprise outputting the first command to the first application programming interface. That is to say, at least one process in the sequence of processes may include sending the command (and any associated data and/or criteria) to the first application programming interface for processing.

Executing the first sequence of processes may further comprise obtaining user information associated with the first client device and outputting the user information to the first application programming interface. In this respect, obtaining user information may comprise communicating with a data storage means storing the user information. For example, the data storage means may comprise user login and account information for the relevant third party API.

The first orchestrator server may be further configured to store an outcome of each process within the first sequence of processes after each said process is completed. That is to say, after each step within the sequence of processes is completed, the outcome and the current state of the sequence may be stored in some memory or storage device of the orchestrator server. In doing so, if an error occurs in the next process within the sequence, the progress up to that point will not be lost and the first orchestrator server can pick up at the last successful point in the sequence, or alternatively, send the first sequence of processes and the record of its progress to another orchestrator server to complete. As such, the first orchestrator server will ensure that the first sequence of processes is run to completion and a result output to the client.

The method may further comprise outputting, from the first cloud based intelligent storage means, a request to a second orchestrator server to initiate the first sequence of processes if the first orchestrator server is unavailable. That is to say, if the first orchestrator server does not initiate the first sequence of processes in response to the request from the first cloud based intelligent storage means, for example, because it does not have any available processing resources due to a high number of incoming commands, the first cloud based intelligent storage means will send another request to a different orchestrator server that is also configured to execute the first sequence of processes. As such, the first cloud based intelligent storage means will ensure that a sequence of processes is initiated for every command that is received, managing the resources used to execute each command according to capacity and availability.

The method may further comprise inputting the result of the first sequence of processes to a second cloud based intelligent storage means, wherein the second cloud based intelligent storage means subsequently outputs the result of the first sequence of processes to the first client device.

The plurality of instructions may be defined by a configuration file stored on the first orchestrator server.

The first command may be received via one of: a telephone call, an SMS text message, an email, a messaging application, a web-based browser or computer application software.

The method may further comprise converting the first command to a suitable data format, and inputting the converted first command to the command processing platform. For example, in the case of text-based message, phone call or email, a communications gateway may be used for converting the messages to be sent via hypertext transfer protocol (HTTP) as an input to the command processing platform.

The first application programming interface may be associated with a medical facility. In such cases, the first function may be at least one of: a request for an appointment, a request for information, or request for a prescription. It will however be appreciated that the first function may be any bespoke action associated with the medical facility. Likewise, it will be appreciated that the first application programming interface may be associated with any other service based organisation.

A further aspect of the present invention provides a system for performing asynchronous communication, the system comprising a command processing platform configured to receive one or more commands from a plurality of client devices to perform a function at one or more third party application programming interfaces, a first cloud based intelligent storage means for storing the received commands, and one or more orchestrator servers configured to store and execute a plurality of instructions for carrying out the received commands, wherein, in response to each received command, the first cloud based intelligent storage means is configured to output a request to a first orchestrator server to initiate a sequence of processes, wherein each sequence of processes is defined by at least a portion of the plurality of instructions, and wherein said first orchestrator server is configured to output a result of the respective sequence of processes for transmitting to the respective client device.

The one or more orchestrator servers may be configured to communicate with a third party application programming interface to carry out a sequence of processes associated with a command, wherein the communicating at least comprises outputting the respective command to the third party application programming interface.

The one or more orchestrator servers may be further configured to obtain user information associated with the respective client device, and output the user information to the third party application programming interface. In such cases, the user information may be obtained from a data storage means.

The first orchestrator server may be further configured to store an outcome of each process within the first sequence of processes after each said process is completed.

The first cloud based intelligent storage means may be further configured to output a request to a second orchestrator server to initiate the first sequence of processes if the first orchestrator server is unavailable.

The system may further comprise a second cloud based intelligent storage means configured to receive the result of the respective sequence of processes from the orchestrator server, and output the result to the respective client device.

The one or more commands may be received via one of: a telephone call, an SMS text message, an email, a messaging application, a web-based browser or computer application software.

The system may further comprise one or more communication gateway nodes for converting the one or more commands to a suitable data format for inputting to the command processing platform.

At least one third party application programming interface may be associated with a medical facility. In such cases, the function may be one of: a request for an appointment, a request for information, or request for a prescription.

Brief Description of the Drawings

Figure 1 is an example of a prior art online booking system; Figure 2 is an example of an asynchronous booking system according to the present

disclosure;

Figure 3 illustrates part of the system of Figure 2; Figure 4 illustrates a further part of the system of Figure 2; Figure 5 illustrates yet a further part of the system of Figure 2; Figure 6 is a sequence diagram of communications between the entities represented in Figure 2.

Detailed Description of the Drawings

As described above, medical facilities and other service based organisations often provide online booking services to allow their users to make appointments or request services via a computing device. Such booking systems 100 are illustrated by Figure 1. The system comprises a client device 102, on which a booking user interface is provided via a web-based browser or computer application software, which allows a user to input booking requests and the like. A web-based central server 104 is also provided, which serves as a backend with the ability to receive and process requests from the client device 102. The central server 104 communicates with a data storage means 106 that stores user data, security data and other relevant data needed for the operation of the booking system 100. The central sever 104 also communicates with one or more third party application programming interfaces (API) 108 provided by the organisation to enable online booking services.

An example of how the system 100 would typically operate will now be described.

Step 1 -User registration In order to use the booking service provided by a third party API 108 (e.g., provided by a GP surgery), the user will first need to register with the central server 104 by creating a username and password combination, along with other added security attributes for multi-factor authentication. For example, the user could use their email address as a username and setup a password for access. They could then use a memorable word, and/or a mobile number for providing other factors for authentication. To do this, the user may initiate a request to set up an account via the client device 102, which may then be sent to the central server 104 for processing.

Once this step has been completed, the access data and user credentials may be stored in the data storage means 106, for example, using a table structure such as: Username Password (hash) Attr-1 (eg: Attr-2 (eg: . Attr -n mobile no.) "memorable" word) user©domain* AQAAAAEAAMNQ*** 078****** [memorableword** ..

** ** ** **]

Table 1

Step 2 -Link user to third party API Once the user is registered with the central server 104, the next step is to link the user's account with the third party API 108. This typically involves the user first providing their online registration details to the central server 104 (i.e., logging into their account using the credentials created in step 1). The central server 104 will then establish a connection for the user with the third party API 108. Typically, the third party API 108 will provide internal credentials for the user that the central server 104 can use when communicating with the third party API 108 in relation to that user. Once the link is established, the data storage means 106 will store the link data, for example, using a table structure such as: Username API -User credential 1 API -User credential 2 (eg: token) ..... API -User credential n (eg: id) user©domain*** ab534318-e34f*** y3he3qr7burur6yym9 nnq** ..

Table 2

Step 3 -Use booking service synchronously Once the user has registered with central server 104, and linked their user account with the third party API 108, the user can simply login and perform tasks synchronously. To begin, a user will login to the central server 104 and request a service (e.g., to book an appointment) via the user interface provided on the client device 102. When using a web-browser, the login-session "cookie" is typically passed with every request to identify the user; the central server 104 will then use this information to fetch the user's API credentials to communicate with the third party API in order to carry out the request. When using a computer application on the client device 102, the user will be authenticated using a standard login form, wherein the application returns some form of API-token or the like to pass to the central server 104 to identify the authenticated user-session upon each request.

Once the user's credentials have been verified, the central server 104 will communicate with the relevant third party API 108 to action the request. In this respect, once the third party API 108 has processed the request, the third party API 108 will send the outcome of the request (e.g., a booking confirmation, an alternative appointment slot) to the central server 104, which will then be communicated back to the client device 102.

However, as described above, each user must necessarily have access to the internet in order to use these booking services, which may not necessarily be the case for all users. The user also only has "synchronous" access to these services, which means that, when booking an appointment, the user cannot do much in the case where there are no appointments available at the instant that they are looking for available slots. This will often result in users continuously "refreshing" the page in the hope that appointment slots may open up. This wastes not only the users' time but also put needless stress on all the systems (e.g., servers, CPUs, etc.) used to implement the booking service.

Overview of the Proposed Solution Figure 2 illustrates an asynchronous booking system 200 according to the present disclosure. The system 200 comprises a plurality of client devices 202A-C, through which users access and communicate with the other components of the system 200. The client devices 202A-C may be any suitable device, for example, a landline telephone, a mobile phone, a computer, a laptop, a tablet, a smart watch or the like. As will be described in more detail below, the user may access and communicate with the asynchronous services using the client devices 202A-C by means of a telephone call, a SMS text message, messaging applications (e.g., WhatsAprm), an email, a web-based browser or computer application software, which may depend on the type of device being used and the functionality supported by those devices.

As before, the system 200 comprises a central server 204 for carrying out user registration and connecting the client devices 202A-C to one or more third party APIs 214, as described in Step 1 and 2 above. The system 200 will comprise a data storage means 206 for storing user data, along with the relevant login data for accessing each of the third party APIs 214 linked to each user.

Once a user has registered with central server 204, and linked their user account with one or more third party APIs 214, the user is able to access the booking services asynchronously using their preferred method of communication, for example, by telephone call (mobile or landline), SMS text message, messaging application, email, or through the use of a web-based browser or computer application software. In any case, the central server 204 ensures that the relevant attributes and data needed to establish and verify the identity of the user are collected and stored in the data storage means 206.

For example, in the case of SMS text message or messaging application, the mobile number of the client device 202A-C will be stored in the data storage means 206 as follows: Username Password (hash) Attr-1 (eg: mobile no.) Attr-2 (eg: .... . Attr -n "memorable" word) user@domain* ** AQAAAAEAAMNQ*** ** 078****** ** [memorableword** **] ..

Table 3

In the case of telephone calls, the mobile number and the landline telephone number of the client devices 202A-C associated with the user will be stored in the data storage means 206 as follows: Username Password (hash) Attr-1 (eg: Attr-2 (eg: Attr-3 Attrn mobile no.) "memorable" word) (land line no.) user@doma in*** AQAAAAEA AMNQ**** * 078******** [memorableword ***Al [020 ****]

Table 4

In the cases of email, web browser or computer application, the email address associated with the user may be sufficient as the first factor of authentication. As an added step, a "challenge" attribute may be collected as well. This could be in the form of a "PIN" or "date of birth", or any attribute that the user is likely to remember and is (potentially) unique to them.

The data storage means 206 will thus also store the "challenge" information as an attribute: Username Password (hash) Attr-1 (eg: mobile no.) Attr-2 (eg: Challen ge (eg: PIN) Att r-n "memorable" word) user@domain *** AQAAAAEAAMNQ* **** 078***** *** [memorableword ***Al 89**

Table 5

It will of course be appreciated that, for each user, all of the data and attributes needed to enable the user to transmit requests (as will be described) by any of the means described herein may be collected and stored in the data storage means 206. In doing so, the user can choose to send requests using whichever means is the most suitable or convenient at that moment in time. For example, if the user does not have access to the internet at a given time, they may send a request using a SMS text message or a telephone call.

Once the user is setup to asynchronously access the booking services, the user may send commands (e.g., booking requests) to be actioned by third party API 214. The commands will comprise an instruction or request, including any specific criteria. In some cases, a set of commands may be published and made available to user with instructions on the usage of each command.

For example, a user could send a SMS text message to the third party API 214 with the command "BOOK Earliest {From 'date' To 'date'}", in order to request the earliest appointment between two sets of dates. To send the same command via a telephone call to a pre-defined number associated with the third party API 214, the command may be logged via the selection of the command from an IVR (Interactive Voice Response) menu, or by leaving a voice message stating the command. As another example, in the case of an email message to a pre-defined email address associated with the third party API 214, the command may be input to the subject line of the email message. In the case of a web browser or computer application, the command may be input via the user interface.

In the case of a command received via a web browser or computer application, no further processing may be required since the command will already be received at the central server 204, for example, as a hyper transfer protocol (HTTP) request (or other suitable format). However, for commands received as SMS text messages, telephone messages or emails, further processing may be required to convert it to the required format (e.g., HTTP). In some cases, this may be done by sending the command to an intermediary processing service, also referred to herein as a communication gateway 205. For example, in the case of telephone calls, a communication gateway 205 in the form of a "voice" API provider may be used to process the telephone call and transmit the required information to the central server 204. The voice API provider will communicate with the central server 204 using "webhooks", which trigger a HTTP request in response to a received telephone message. Similar communication gateways may also be implemented for SMS text messages for converting said messages into HTTP requests that are then transmitted to the central server 204. For email commands, an email service provider supporting "plugins" that allow bespoke code to be run whenever an email received to a particular email address, the information contained within the email thus being converted to a HTTP request for input to the central server 204.

Once the command has been passed through a communication gateway and converted to the appropriate format, the command is sent to a command processing platform 208. The command processing platform 208 may be a cloud-based platform comprising a set of instructions configured to be run when a pre-defined event occurs (e.g., a command is received). The primary functions of the command processing platform 208 are to produce a challenge response to the user (where required), and store the command (once authenticated) to a first cloud based intelligent storage means 210, referred to hereafter as the "command list store" 210.

The command processing platform 208 is not deployed on a traditional "server", but is deployed on an infrastructure that can be configured to invoke the piece of code whenever an event occurs, for example, whenever a command is received. As such, only very minimal resources (e.g., memory/CPU) are being used when there are no events to be processed. Further, the intelligent underlying cloud infrastructure (i.e., the command list store 210) will automatically manage the provision of the necessary resources, for example, using virtualisation and/or containerization technology, as and when those are required. As such, resources do no need to be allocated up-front on the basis that a fixed high level of usage is required all the time, thereby providing cost and energy savings. Furthermore, the amount of resources used can be managed according to the number of commands being processed at a given time.

The command list store 210 is further illustrated by Figure 3. The command list store 210 stores each command that is input by the command processing platform 208, along with the criteria of the command and the relevant user attribute. For example, when the user sends a command using SMS text message, the data stored in the command list store 210 is as follows: Relevant User Attribute Command Criteria Eg: Mobile number: BOOK Earliest From date / To date 07*********

Table 6

When the user sends a command using a telephone call, the data stored in the command list store 210 is as follows: Relevant User Attribute Command Criteria Eg: Tel number: BOOK Earliest From date / To date 02*********

Table 7

As shown in more detail in Figure 3, on receipt of a command, the command list store 210 will automatically instruct a server 211 comprising orchestration software (referred hereinafter as the orchestrator server 211) to initiate a new master sequence process 212A-C, each master sequence process comprising a workflow defining set of tasks and processes that need to be carried out in order to act on the command. In this respect, the orchestrator server 211 is configured to store and run (e.g., memory and CPU) a plurality of instructions for performing the workflow associated with each possible command for the services associated with a given third party API 214, including details of the inputs and outputs of each process within the workflow. It will of course be appreciated that orchestrator server 211 may be cloud-based or provided on any suitable computing hardware.

In prior systems, commands or requests received from different users are typically placed into a queue and "polled" for data, and action is taken based on new information in these queues. These types of traditional queue management systems are hard to implement and often struggle with scale and performance, and are prone to errors. However, in the present disclosure, a new master sequence process 212A-C will be initiated in the orchestrator server 211 each time a command is received by the command list store 210.

That is to say, each time a command is received, it is not simply placed into a queue for processing, but rather it prompts its own sequence of tasks that are actioned independently from other commands that have been received. The master sequence processes 212A-C can be initiated at the same time or in any order, and not necessarily in the order the commands were received by the command list store 210.

Figure 4 further illustrates an example of a master sequence process 400, which may be any of the master sequence processes 212A-C shown in Figures 2 and 3, from which it can be seen that each sequence (or workflow) is a set of individual processes 1 to "n" that are needed in order to act on the received command. In this respect, all of the data associated with the command is passed to the master sequence process 400. Each process is defined by a piece of code with defined input parameters and output data structures, which is stored in the orchestrator server 211. Each process completes a specific step to achieve the necessary outcome. The master sequence process 400 is defined by code or by a configuration, wherein the sequence is stored as a file defining each step of the sequence and providing details of how each step in the sequence maps to a particular bit of code or another configuration file. In the case of a booking request, the first process in the master sequence 400 may be to obtain the credentials of the user for linking to the third party, the second process may be to request availability from the relevant third party API 214, and so on until an appointment has been booked, the final process being to output the confirmation of the booked appointment (i.e., the outcome of the command).

The resources for each individual process are managed by the underlying infrastructure of the command list store 210, which ensures that each master sequence process 400, is created and run to completion, with all the necessary resources being managed automatically. In this respect, the command list store 210communicates with the orchestration software provided on an orchestrator server 211 that is configured to run each sequence of functions with the ability of maintaining the results of each function, and recover from any hardware or software issues. These functions may be performed in different ways, but commonly by maintaining data on processes that are being run at a given moment in time in a separate data store and having the capability to call in new resources, such as CPU and memory, as and when required. That is to say, upon the receipt of each command, the command list store 210 will invoke a suitably configured orchestrator server 211 to start carrying out a new master sequence process 212A-C and determine that the master sequence process 212A-C has started on the given orchestrator server 211. In the event that an orchestrator server 211 fails to start, the command list store 210 will not lose the command and will continue to attempt to invoke a configured orchestrator server 211 until a successful start-up is achieved. That is to say, the command list store 210 will ensure that a configured orchestrator server 211 starts running through the steps of the master sequence process 212A-C. In this respect, it will be appreciated that more than one orchestrator server may store the instructions needed to run the master sequence processes associated with a given third party API 214.

Once an orchestrator server 211 has initiated a master sequence process 212A-C, it will ensure that the sequence of processes is run to completion. In this respect, the orchestrator server 211 will be configured to store (e.g., in memory) the current state of the master sequence process 212A-C after each process within the sequence has been completed. Consequently, if there is an error performing one of the processes, the progress through the sequence will not be completely lost, and the orchestrator server 211 can return to the last successful point within the sequence and attempt the next step again, continuing until the master sequence process 212A-C has run to completion. If the orchestrator server 211 continues to be unsuccessful, it can then send an error notification to the administrator with details of the error, or send the master sequence process 212A-C and the record of its current state to another orchestrator server to complete.

Once the final process in a master sequence process 400 has been completed, the output result is published to a second cloud based intelligent storage means 216, referred to hereafter as the "command output list store" 216, which is configured to store the results of each command.

As illustrated by Figure 5, the command output list store 216 is similar to the command list store 210, in that it will automatically initiate an output process 502A-B as soon as a result of a command is received. The output process 502A-B comprises logic that is configured to send the results of the original command to the client device 202A-C of the user. Typically, the output process 502A-B will comprise one process to be completed (i.e., send the result to the user), however, it will be appreciated that the output process 502A-B may be implemented as a further set of master sequence processes if additional processes are required. As with the master sequence processes 212A-C described above, the output processes 502A-B may be performed by a server comprising orchestration software. The results of the command will then be sent to the client device 202A-C using the same method by which the command was sent, passing the result through a communication gateway if required. For example, if the command was sent by SMS text message, then the result will also be sent by SMS text message.

As such, by providing a system 200 whereby the processing of each command can be performed separately and independently of one another, rather than placing each command in a queue for processing, communication between a plurality of users and a third party service party may be performed asynchronously and in a scalable way, thus allowing large quantities of commands to be carried out in parallel without undue pressure on the underlying infrastructure. Additionally, this allows users to send a command (e.g., a request for an appointment) and then be notified when the actual command has been carried out, rather than needing to stay online. Likewise, by providing certain criteria, users can issue commands to be executed in the future, for example, they can issue a command to book an appointment 10 days from the date of the request, or request a prescription 5 days from the date of the request.

Further still, there is no need for a user to have access to the Internet since commands can be sent over SMS text message or telephone. This is particularly advantageous in scenarios where an internet connection is not available or patchy, for example, while travelling on a train. Likewise, it helps users who are more comfortable dealing with phone calls or text messages to make use of the automated booking services, rather than requiring the use of smartphone or computer.

Example

An example of the system 200 in use will now be described with reference to Figure 6. In this example, the user is a patient of a general practice (GP) surgery, and is seeking to book the earliest available appointment with a doctor between 1 July and 10 July. The user has previously registered with the GP surgery API 214 via the central server 204 and is setup to access the booking services asynchronously. In this case, the user is an elderly patient who only has a phone 202N that is configured to send SMS text messages or telephone calls. At step 600, the patient sends a command via SMS text message, the command being to "BOOK EARLIEST" and having the criteria "From 1 July To 10 July", which is received at the central server 204. As described above, as the command has been sent by SMS text message, it will be passed through some intermediary processing software for converting the SMS text message into a compatible format for processing by the central server 204. At step 602, the central server 204 may send a request back to the user device 202N for security information needed to verify the identity of the user. For example, the user may be requested to provide certain characters of a memorable word or PIN, to thereby ensure that the command originated from the user device 202N associated with the user's account. For example, it may be possible to imitate a mobile phone number so that a text message appears to be sent from a specific device. However, when the request of security information is sent, it will be delivered to the real device of the user, and thus any response back can be considered as coming from the device of the authorised user. The user device 202N will then send the required information back to the central server 204 for verification at step 604.

At step 606, the central server 204 will send a request to the data storage means 206 to verify the credentials of the patient, for example, based on the telephone number that sent the text message and/or the security information provided at step 604. At step 608, the data storage means 206 will send back the required data so that the central server 204 can verify the identity of the user. At step 610, the central server 204 will send the command to the command processing platform 208. At step 612, the command processing platform will input the command into the command list store 210, which will automatically instruct an orchestrator server 211 to initiate a master sequence process in response thereto (step 614).

The orchestrator server 211 will then perform the relevant master sequence process for the received command, running through the list of processes to thereby action the command. For example, at step 616, the orchestrator server 211 will request the patient's credentials and login details associated with the GP surgery API 214 as the first process in the master sequence process, which will be sent back to the orchestrator server 211 at step 618. At step 620, the orchestrator server 211 will send a request to the GP surgery API 214 comprising the details of the command, that is, the action needed and the criteria.

At step 622, the GP surgery API 214 will send back a communication comprising a result of the command, for example, either an indication that no appointments are available in that time frame, or an appointment booking confirmation (e.g., llam on 4th July).

At step 624, as the final process to be completed, the orchestrator server 211 will send the result of the command to the command output list store 216. This will then initiate an output process to send the result of the command back to the client device 202N at step 626. In this respect, the result of the command will be sent back to the patient via SMS text message, as their preferred method of communication.

Whilst the above describes the processing of a single command, it will be appreciated that in practice, any number of commands may be received and processed in parallel. As discussed above, a new master sequence process will be initiated in a suitably configured orchestrator sever 211 each time a command is received, rather than placing the commands in a queue for processing, each master sequence process being actioned independently of one another. Furthermore, the command list store 210 is configured to ensure that a new master sequence process is initiated by an available orchestrator server 211, and thus commands are allocated according to the availability of resources. In doing so, large number of commands can be processed in parallel, with minimal resources being used when there are no commands to be processed.

Various modifications, whether by way of addition, deletion and/or substitution, may be made to all of the above described embodiments to provide further embodiments, any and/or all of which are intended to be encompassed by the appended claims.

Claims

Claims 1. A method of asynchronous communication, the method comprising: receiving, at a command processing platform, a first command from a first client device to perform a first function at a first application programming interface; inputting the first command to a first cloud based intelligent storage means; outputting, from the first cloud based intelligent storage means to a first orchestrator server, a request to initiate a first sequence of processes in response to the first command, wherein the first sequence of processes comprises a plurality of instructions for carrying out the first command; executing, at the first orchestrator server, the first sequence of processes, wherein the executing at least comprises communicating with the first application programming interface; and outputting a result of the first sequence of processes to the first client device.
2. A method according to claim 1, wherein communicating with the first application programming interface comprises outputting the first command to the first application programming interface.
3. A method according to claim 1 or 2, wherein executing the first sequence of processes further comprises obtaining user information associated with the first client device and outputting the user information to the first application programming interface.
4. A method according to claim 3, wherein obtaining user information comprises communicating with a data storage means storing the user information.
5. A method according to any preceding claim, wherein the first orchestrator server is further configured to store an outcome of each process within the first sequence of processes after each said process is completed.
6. A method according to any preceding claim, further comprising outputting, from the first cloud based intelligent storage means, a request to a second orchestrator server to initiate the first sequence of processes if the first orchestrator server is unavailable.
7. A method according to any preceding claim, further comprising inputting the result of the first sequence of processes to a second cloud based intelligent storage means, wherein the second cloud based intelligent storage means subsequently outputs the result of the first sequence of processes to the first client device.
8. A method according to any preceding claim, wherein the plurality of instructions are defined by a configuration file stored on the first orchestrator server.
9. A method according to any preceding claim, wherein the first command is received via one of: a telephone call, an SMS text message, an email, a messaging application, a web-based browser or computer application software.
10. A method according to any preceding claim, wherein the method further comprises converting the first command to a suitable data format, and inputting the converted first command to the command processing platform.
11. A method according to any preceding claim, wherein the first application programming interface is associated with a medical facility.
12. A method according to claim 11, wherein the first function is at least one of: a request for an appointment, a request for information, or request for a prescription.
13. A system for performing asynchronous communication, the system comprising: a command processing platform configured to receive one or more commands from a plurality of client devices to perform a function at one or more third party application programming interfaces; a first cloud based intelligent storage means for storing the received commands; and one or more orchestrator servers configured to store and execute a plurality of instructions for carrying out the received commands; wherein, in response to each received command, the first cloud based intelligent storage means is configured to output a request to a first orchestrator server to initiate a sequence of processes, wherein each sequence of processes is defined by at least a portion of the plurality of instructions; and wherein said first orchestrator server is configured to output a result of the respective sequence of processes for transmitting to the respective client device.
14. A system according to claim 13, wherein the one or more orchestrator servers are configured to communicate with a third party application programming interface to carry out a sequence of processes associated with a command, wherein the communicating at least comprises outputting the respective command to the third party application programming interface.
15. A system according to claims 13 or 14, wherein the one or more orchestrator servers are further configured to obtain user information associated with the respective client device, and output the user information to the third party application programming interface.
16. A system according to claim 15, wherein the user information is obtained from a data storage means.
17. A system according to any of claims 13 to 16, wherein the first orchestrator server is further configured to store an outcome of each process within the first sequence of processes after each said process is completed.
18. A system according to any of claims 13 to 17, wherein the first cloud based intelligent storage means is further configured to output a request to a second orchestrator server to initiate the first sequence of processes if the first orchestrator server is unavailable.
19. A system according to any of claims 13 to 18, further comprising a second cloud based intelligent storage means configured to receive the result of the respective sequence of processes from the first orchestrator server, and output the result to the respective client device.
20. A system according to any of claims 13 to 19, wherein the plurality of instructions are defined by a configuration file stored on the first orchestrator server.
21. A system according to any of claims 13 to 20, wherein the one or more commands are received via one of: a telephone call, an SMS text message, an email, a messaging application, a web-based browser or computer application software.22. A system according to any of claims 13 to 21, wherein the system further comprises one or more communication gateway nodes for converting the one or more commands to a suitable data format for inputting to the command processing platform.
22. A system according to any of claims 13 to 22, wherein at least one third party application programming interface is associated with a medical facility.
23. A system according to claim 22, wherein the function is one of: a request for an appointment, a request for information, or request for a prescription.