GB2566456A

GB2566456A - Request broadcasting

Info

Publication number: GB2566456A
Application number: GB1714689.5A
Authority: GB
Inventors: De Pace Claudio
Original assignee: Digital Home Visits Tech Ltd
Current assignee: Digital Home Visits Tech Ltd
Priority date: 2017-09-13
Filing date: 2017-09-13
Publication date: 2019-03-20
Also published as: WO2019053433A1; GB201714689D0

Abstract

A computer-implemented method of delivering a job offer to a set of remote workers, comprising: receiving a job request having a start time 402; generating a set of workers that are compatible with the job request 404; receiving a profile of each of the workers; generating a matching score for each worker in the list, by comparing the profile of each worker to the job request, the score indicative of the suitability of each worker to the job; transmitting a job offer to the best-scoring worker; if they do not accept the job offer within a first interval, transmitting the job offer to the second best-scoring worker; and if the job is not accepted by any worker within a second interval, transmitting the job offer to the third best-scoring worker; such that each interval is calculated based on at least one characteristic of at least one worker profile.

Description

REQUEST BROADCASTING

Technical field

Embodiments of the present invention generally relate to methods and systems of broadcasting offers to devices and in particular to offers which require a positive reply within a given time period, and has particular application to job allocating networks where job offers are broadcast to potential workers.

Background

In the advent of online peer-to-peer job-allocating platforms, potential customers are put into direct contact with potential providers of a service, resulting in elimination of the middle man.

Known peer-to-peer job-allocating platforms first receive a job request from a potential customer. This job request is broadcast as a job offer from a server of the platform to potential providers that are suitable for the job. When a potential provider accepts the job, the server is updated and the job is assigned to that provider who subsequently provides the service to the customer. In such a system, the message is broadcast to many potential providers, whereas only one provider can successfully be assigned the job. Potential providers can therefore receive job offers that do not result in them being assigned the job, even if they accept the job offer. In other words, job offers are received, but before the provider accepts, the job has already been assigned to another provider. Such a peer-to-peer platform can thus result in an inefficient and/or unreliable job broadcasting system where a low proportion of acceptances actually result in assigned jobs.

Further, in many industries, the job to be completed does not have a flexible start time, and so there is a strict time constraint on allocating the job successfully.

Further, in certain industries, such as the social care (for example elderly care) industry, the nature of the jobs to be allocated and the suitability of a provider/worker for completing the job vary for each job request. The job requests therefore cannot be easily characterised quantitatively, and it is therefore difficult to provide an automated online peer-to-peer platform for those industries, which is reliable for the potential customer.

Summary

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

In a first aspect of the invention, there is provided a computer-implemented method according to CLAIM 1. Advantageously, the method increases the reliability of a job broadcasting system such that the proportion of acceptances that results in assigned jobs is increased.

It may be that the method further comprises the steps according to CLAIM 2, which allows the job offer to be broadcast to all available workers where it is determined that the time until the start time of the job is too soon (i.e. too urgent) to send out job offers consecutively. Advantageously this increase the likelihood of a job being successfully assigned in time whilst still maintaining a reliable job broadcasting system where possible.

It may be that the method comprises the features according to any one of CLAIMS 3 TO 10. Such features increase the probability that the job will be assigned to a worker which is more suitable to the job.

It may be that the method comprises the features of CLAIM 11. Advantageously, the job offering process terminates with a predetermined time period remaining so that the person requesting the job has sufficient time to allocate the job elsewhere.

In a second aspect of the invention, there is provided a server according to CLAIM 12. Advantageously, the server may have to send the job offer to fewer worker devices before it is successfully assigned.

In a third aspect of the invention, there is provided a computer program product according to CLAIM 13.

Brief description of the drawings

Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.

FIG. 1 is a schematic showing a peer-to-peer platform according to an embodiment of the invention;

FIG. 2 is a diagram showing a job-allocating process of a peer-to-peer platform according to an embodiment of the invention;

FIG. 3 is a diagram showing how a customer submits a job request to the peer-to-peer platform according to an embodiment of the invention;

FIG. 4A is a diagram showing how a queue of potential workers for a job is generated from a received job request according to an embodiment of the invention;

FIG. 4B is a schematic illustrating the filtering of incompatible potential workers based on a received job request, according to an embodiment of the invention;

FIG. 4C is a schematic illustrating a quantitative scoring scale of a potential worker according to an embodiment of the invention;

FIG. 4D is a schematic showing a generated queue of potential workers for a job according to an embodiment of the invention;

FIG. 5A is a schematic illustrating a decision tree algorithm for generating and sending job offer messages according to an embodiment of the invention;

FIG. 5B is a schematic illustrating a decision tree algorithm for assigning a job based on replies to a job offer message according to an embodiment of the invention;

FIG. 6A is a schematic illustrating a group broadcast message according to an embodiment of the invention; and

FIG. 6B is a schematic illustrating a cascaded broadcast message according to an embodiment of the invention.

Detailed description

Those skilled in the art will recognise and appreciate that the specifics of the examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.

FIG. 1 shows a peer-to-peer platform 100 according to an embodiment of the invention. The peer-to-peer platform comprises a server 102, which is wirelessly (i.e. remotely) connected to a manager device 104, worker devices 106n, a customer device 108 and a next-of-kin device 109. The server 102 comprises a communications interface (not shown) which allows the server 102 to communicate and transfer data with the wirelessly connected devices. The server further comprises a processor 122, a memory 112 and hosts a portal 110. The processor 122 is configured to perform instructions 116 saved in the memory 112.

The customer device 108 and/or the next-of-kin device 109 is able to access a customer section of the portal 110. The customer device 108 and the next-of-kin device 190 is able to register with the platform 100 using the portal 110. Upon registering using the portal 110, a customer profile of the customer device 108 (including credential information) is saved in a customer profile log 120 in the memory 112. The customer device 108 and the next-of-kin device 109, where applicable, is able to access the customer profile by providing the credentials to the portal 110. The customer or the next-of-kin device is also able to submit job requests through the portal 110 on customer device 108 or the next-of-kin device 109, and specify certain requirements or preferences for the job. Once a worker has been assigned to the job, the customer or next-of-kin devices 108, 109 are also able to view details of the worker assigned to the job, and to received notifications when the worker has begun the job, including real-time tracking of the completion of tasks. The customer profile log 120 also saves a calendar of customer with upcoming jobs and details regarding the job, including whether a worker has been assigned and, if so, which worker has been assigned the job.

Similarly, worker devices 106n are able to access a worker section of the portal 110 and register with the platform. Upon registering, a worker profile of the relevant worker device 106n is saved in a worker profile log 114 of the memory 112. The worker is able to receive job offers and accept or decline offers through the portal 110 on the particular worker device 106n. The worker is also able to check in and out of a job using the worker device 106n, and to mark tasks as complete in real-time during the job.

The worker profile log 114 saves a history of worker activity, including some or all of: which client the worker has worked for in the past, response time when replying to job offers, latest location of the worker device 106n, qualifications of the worker, languages spoken, any restrictions of the workerjob performance ratings which are submitted to the server by the client device 108 or next-of-kin device 109 upon completion of a job, and a points rating. The worker profile log 114 also includes a calendar of the workers with upcoming jobs which have been assigned to the workers, including details about the upcoming job and the customer profile associated with it.

The points rating is calculated adding up the total number of points a worker has received. Positive points are awarded to the worker for positive behaviour; for instance, the worker gains points for checking into jobs on time, accepting jobs, and a higher job performance rating. Negative points are awarded to the worker for undesirable behaviour such as: last minute cancellations, poor job performance rating or not replying to job offers which are offered to them by the server 102.

The manager device 104 is able to access a manager section of the portal 110. By providing credential information to the portal 110, the manager device is able to access other data 118 saved in the memory 112, such as an overview of worker profiles and customer profiles, instructions 116, an overview of completed jobs, an overview of scheduled jobs and an overview of billing and payment information. The manager device 104 is also able to receive notifications from the server 102 about upcoming jobs (for example urgent jobs which have still not been assigned to a worker, or jobs which have been cancelled). The manager device 104 is also able to receive notifications about an assigned worker which has not initiated an assigned job or closed an assigned job session (i.e. a failed check-in or check-out). The user of the manager device 104 is also able to contact workers (or worker devices 106n) directly, and to re-negotiate a job offer (for example where a job becomes urgent and does not have a worker assigned), and is able to reset a worker queue for a job (e.g. to refresh the list of workers to whom the job has been offered).

The worker profile log 114 is updated by worker activity on the device 106n. For example, the worker profile log 114 includes the time device 106n last logged on to the portal 110. Device 106n can also send the location of the device 106n when logged on to the portal 110 so that the worker profile log 114 contains a log of the most recent location of the device 106n.

The platform 100 is thus able to, via the server 102: receive job requests from the customer device 108 and/or the next-of-kin device 109; to communicate job offers to the worker devices 106n and received replies form the worker devices 106n; to assign the jobs to a given worker device 106n (i.e. to a particular user of the worker device 106n) based on instructions 116 saved in the memory 112 of the server 102; and to provide the manager device 104 with an overview of various data.

FIG. 2 shows a job-allocating process 200 of the peer-to-peer platform 100 according to an embodiment of the invention. In a first step 202, a customer requests a job and the job request is sent to the server 102 in step 204 (i.e. the customer logs in to the portal 110 on the device 108 and creates and submits a job request through the portal 110).

Next, in step 206 the server 102 performs a matching algorithm, saved in the instructions 116, to generate a queue of potential workers. The matching algorithm of the present embodiment is described in further detail with reference to FIGs. 4A-4D.

The server 102 then sends the job offer to the workers that are members of the queue according to a delivery algorithm, saved in the instructions 116 (step 208) and sends alerts to the manager device 104 where necessary according to the delivery algorithm (step 210). The delivery algorithm of the present embodiment is described in more detail with reference to FIGs. 5A and 5B.

In step 212, the server receives one or more replies from the worker devices 106n which may be acceptances (YES replies) or rejections (NO replies).

In step 214, the job is assigned according to the delivery algorithm, based on the replies received from the worker devices 106n. A notification is then sent from the server 102 to the worker device 106n of the assigned worker (step 218), and the server is updated, for example by updating a calendar of the worker profile, the customer profile and updating the overview data that is viewable by the manager device 104.

FIG. 3 shows how a customer submits a job request to the peer-to-peer platform 100 according to an embodiment of the invention. In a process 300, a customer enters the details of a job they wish to be complete, for example the type of job, date of the job, and start and finish times of the job (step 302).

The customer then sets hard requirements of the job, which the worker must be able to meet (step 304). Examples of the hard requirements may be, for instance, a required spoken language, tasks that the worker must be able to perform, or a furthest acceptable distance between the customer and potential workers. In some embodiments, some hard requirements may be saved in the customer profile so that those hard requirements are automatically set for each new job request.

In step 306 the customer sets some further preferences which they would prefer for a potential worker. In some embodiments, the preferences may be selected from: distance of worker from customer; interests of worker; worker has worked for the customer in the past; worker rating (either global or from the customer); skills (for instance qualifications); and reliability of the worker. The customer can weight each preference based on the importance of each preference. In some embodiments the customer may add as a preference a set of tasks that need to be performed during the job. The server 102 keeps track of all possible tasks in extensible lookup tables saved in the memory 112. The set of tasks are customisable by the operator of the manager device 104. When a client profile is created, the operator defines a typical selection of tasks associated to it which is then used as blueprint for the visit template. When creating a new visit the operator of the manager device 104 can override the defaults values (tasks) extracted from the profile.

In step 308 the customer requests the job and the request is sent to the server 102 (step 310).

FIG. 4A shows how a queue of potential workers for a job is generated from a received job request according to an embodiment of the invention. In a first step 402, the server 102 receives a job request from the client device 108. A list of available workers is then retrieved from the worker profile log 114 (for example, any workers that are currently or recently active).

In step 406, the worker profiles retrieved from the worker profile log 114 in step 404 are then filtered, and any workers that do not fulfil the hard requirements specified in the job request are removed from the list. In other words, incompatible workers are removed from the list. More specifically, a set of workers that are compatible with the job request is generated. For example, a job request may require a spoken language of the worker, and any worker profiles that do not specify that language as being spoken are removed from the list. In another example, the job request may specify a number of dates and times that the worker must be available. Any workers that do not have availability during those dates and times are removed from the list. The skilled person will of course appreciate that many combinations of hard requirements are possible, and depend on the type and nature of the platform 100 and the jobs being requested.

In step 408, the remaining workers in the list are scored based on how well each worker profile matches with the preferences of the job request that have been specified by the client (i.e. a matching score for each worker in the list is generated, the matching score being indicative of the suitability of each worker to the job).

In step 410 a queue of workers is generated based on the calculated scores, so that the highest scoring worker is placed first in the queue, followed by the second highest scoring worker and so on.

Optionally, in a step 412 the workers in the queue are then each marked as either a priority worker or a non-priority worker. For example, workers whose score is above a predetermined threshold are marked as priority workers, and the remaining workers are marked as non-priority workers.

FIG. 4B illustrates the filtering of incompatible potential workers based on a received job request, according to an embodiment of the invention. According to the process outlined with reference to FIG. 4A, a list of available workers (420, 422, 424, 426, 428) are retrieved from the memory 112. In the step 406, the list of workers is compared to a set of hard requirements (REQ 1, REQ 2, REQ 3) of the job request. It is found that profiles 422 and 424 do not fulfil one or more of the hard requirements and so they are removed from the list. A new list comprising the compatible profiles 420, 426 and 428 is generated and these profiles are scored based on the preferences of the job request (step 408).

FIG. 4C illustrates a quantitative scoring scale of a potential worker according to an embodiment of the invention. In the embodiment, the job request is submitted with a preference for workers whose location (or most recently logged location) is within a given distance to the customer’s location. As shown in the scoring scale, any workers within the specified distance (i.e. within the offset of the origin) are given a score of 1 or 100%. Outside of this offset, the score decays to zero. The decay can be linear, Gaussian or exponential. For example, a worker whose distance from the customer is d is given a score of 0.5 or 50%.

This scoring scale or a similarly decaying scoring scale can be applied to any quantifiable preference. For instance, where a preference is given for workers whose job performance rating or points are above a certain value, a score of 1 or 100% can be given to workers meeting that criterion, and a worker whose rating is below the value receives a score between 0 or 0% and 1 or 100% based on a decaying scoring system.

Other preferences, such as that the worker has worked for the customer in the past, or the set of tasks to be performed, can be scored in a binary scoring system. In other words, workers that have worked for the customer before will be scored 1 or 100%, and workers that have not worked for the customer before will be scored 0 or 0%.

In some embodiments where a number of preferences are specified in the job request, a total score can be generated from adding the individual scores together. In some embodiments, each score is also weighted and a total score is calculated by adding the weighted scores together. The customer is also able to specify the weightings in the job request, based on how important the customer considers each weighting to be.

FIG. 4D shows a generated queue 450 of potential workers for a job according to an embodiment of the invention. In the queue 450, a set of profiles A-F have been scored. For instance, profile A has received a score of 72% and profile F has received a score of 44%. In the present embodiment, workers have been marked as priority workers if their total score is 65% or above. Profiles A, B and C have therefore been marked as priority workers, and form a priority group 452. Profiles D, E and F have scores below 65% and therefore form a group of non-priority workers 454.

FIG. 5 A illustrates a decision tree algorithm 500 for generating and sending job offer messages according to an embodiment of the invention. First a job offer is received (502) at a time T_req, for a job having a start time of Tj_Ob. The server 102 calculates the time left until the job start time, from the time the job was requested (in other words, T_req - Tjob).

If the time left until the job start time, calculated from the time the job was requested, is less than a predetermined threshold (504), then the server 102 broadcasts the job offer to all compatible workers at once. The predetermined threshold is selected to be indicative of a relatively urgent job, so that jobs that have been requested with a calculated time below this threshold are considered as urgently requiring an assigned worker. In these cases, the priority is to assign a worker as soon as possible, rather than sending out job offers to workers consecutively in an optimally efficient manner.

If the time left until the job start time, calculated from the time the job was requested, is greater than a predetermined threshold (512), then the server transmits the job offer to the highestscoring worker only, in a queue of workers such as that depicted in FIG. 4D (i.e. to profile A in the example of queue 450). As the predetermined threshold is selected to be indicative of urgency, a job request whose time until the job start time (calculated from the time of the request) is greater than the threshold can be considered as not yet urgently requiring the job to be assigned to a worker. In these cases, the priority is to send the job offer to workers in a consecutive sequence in an efficient manner (i.e. to reduce the number of false job acceptances, wherein a worker replies to accept a job which has already been assigned).

In either of these cases (504, 512), different messages may be broadcast in different cases. First, where the job consists of a single task or set of tasks - for example, a job requiring one visit (506, 514) - the message may be:

Subject: Vida-{{ref_code}} URGENT Job Offer

Hi {{carer:first_name}}, we need a Carer on the {{visit:start_date}} from {{visit:start time}} until {{visit:end_time}} in {{visit:location_district_city}}. The client is a {{clientage}} year old {{clientgender}}, and her/his Medical Conditions are {{client:medical_conditions}}. The total payment is {{visit: carer_total_ pay_rate}}.

We would really like you to accept this {{visit:total_duration}} {{visittype}} shift. Please check your calendar and reply as soon as possible with YES to accept or NO to decline the job. The first Carer who accepts will get the job. You can also call Vida for any questions.

<buttons> YES NO

Kind regards, <Vida Care signature>

In a second case where the job consists of a number of tasks or sets of tasks - for example a job requiring a number of consecutive visits (508, 516)- the message may be:

Subject: Vida-{{ref_code}} URGENT Job Offer

Hi {{carer:first_name}}, we need a Carer from the {{visit:start_date}} until {{visit:end_date}} at {{visit: start_8 time}} until {{visit:end_time}} in {{visit:location_district_city}}. The client is a {{clientage}} year old {{clientgender}}, and her/his Medical Conditions are {{client:medical_conditions}}. The total payment is {{visit: carer_total_pay_rate}}.

<buttons> YES NO

Kind regards, <Vida Care signature>

In a third case where the job consists of a number of tasks or sets of tasks which have repeated scheduling - for example a job requiring one or more visits per week (510, 518)- the message may be:

Subject: Vida-{{ref_code}} URGENT Job Offer

Hi {{carer:first_name}}, we need a Carer from the {{visit:start_date}} until {{visit:end_date}} every {{visit:wek_day_repetition}}, at {{visit: start_time}} until {{visit:end_time}} in { {visit:location_district_city} }.

The client is a {{clientage}} year old {{clientgender}}, and her/his Medical Conditions are {{client: medical_ conditions}}. The total payment is {{visit:carer_total_pay_rate}}.

<buttons> YES NO

Kind regards, <Vida Care signature>

The predetermined threshold for the time until the job start time, as measured from the time the job was requested, may depend on the nature of the platform 100 and on the nature of the job being requested. In some examples, the time threshold may by 48 hours.

FIG. 5B illustrates a decision tree algorithm 600 for assigning a job based on replies to a job offer message according to an embodiment of the invention. First, a reply to a job offer is received or an amount of time has elapsed since the job offer was first sent to a worker device 106n (602). The algorithm first depends on whether Tj_Ob - T_req is less than or greater than the predetermined “urgency” threshold (604 or 626).

Tjob - Treq less than the predetermined threshold

If Tjob - T_req is less than the predetermined “urgency” threshold as discussed with respect to FIG. 5 A (604), then the message has been broadcast to all compatible worker devices 106n. The server 102 then awaits for replies from the worker devices 106n in order to assign the job. In this case, there are a number of possible scenarios.

A first scenario 606 is that no positive replies are received from the worker devices 106n (e.g. no workers have replied to the offer, or all workers that have replied, have declined the offer). In this scenario 606, if there have been no positive replies and the time until the start time of the job Tjob is less than a first predetermined amount Ti (608), the server 102 sends a notification to the manager device 104 to notify the manager that there still hasn’t been a worker assigned with the time left until the job being Ti.

If further time has elapsed and the time until the start time of the job Tj_Ob is less than a second predetermined amount T2 (610), the server 102 sends a second, more urgent notification to the manager device 104 to notify the manager that there still hasn’t been a worker assigned, with the time left until the job being T2.

If yet further time has elapsed and the time until the start time of the job Tj_Ob is less than a third predetermined amount T3 (612), then the job offering process is cancelled, and the server 102 notifies the client device and/or next-of-kin device that a worker could not be found for the job. Optionally, the server 102 also sends a notification to the manager device 104 that the job request was unsuccessful.

The values of Τι, T2 and T3 depend on the nature of the platform 100 and the type of jobs requested. In some examples Ti is set as 24 hours or 12 hours, and T2 is set as 8, 5 or 3 hours. It will be appreciated by the skilled person that while only two notifications are sent to the manager device 104, any number of notifications can be sent to the manager device at predetermined times if no workers have accepted the job offer. T3 is set so that the client is given sufficient warning before the start time of the job that no workers could be assigned to the job, so that the client is still able to make alternative arrangements. In some examples, T3 is set at 1 or 2 hours.

In a second scenario 614, a worker replies to decline the job offer. The server 102 replies to the worker device 106n to acknowledge the reply. If there are more workers in the queue that have yet to reply to the job offer (616), then the server awaits the replies and the job offer remains pending (i.e. awaiting a worker to assign the job to). If there are no more workers in the queue i.e. all workers have replied declining the job offer (618), then the server 102 sends a notification to the manager device 104 that all workers have declined the job offer. The manager is then able to generate a queue of new workers or contact the workers directly to try to re-negotiate the job offer, in order to successfully assign the job to a worker.

In a third scenario 620, a worker replies using the worker device 106n to accept the job offer. If the job has not yet been assigned (622), then the job is assigned to that worker and the server 102 updates the relevant information in memory 112. The worker device 106n is sent a notification from the server that it has successful been assigned the job, and the client device 108 is sent a notification that a worker has been assigned the job. The worker is then able to access further information about the job through the portal 110, and the client is able to access information about the worker that has been assigned the job. Optionally, the manager device 104 is also sent a notification that the work device 106n has been assigned the job. The job offer process is also terminated for the other worker devices 106n (for example, a notification is sent to the remaining worker devices that the job has now been assigned, or the job offer is retracted by the server). If a worker replies to accept the job offer but the job has already been assigned (624), then the server 102 notifies the worker via the worker device 106n that the job has been assigned and is no longer available.

Tjob - Treq greater than predetermined threshold

The above applies for when Tj_Ob - T_req is less than the predetermined “urgency” threshold as discussed with respect to FIG. 5 A. In cases where If Tj_Ob - T_req is greater than the predetermined “urgency” threshold (616), then the server has transmitted the job offer to the highest-scoring worker only, in a queue of workers such as that depicted in FIG. 4D. As in the case of Tj_Ob - T_req being less than the predetermined “urgency” threshold, there are also three possible scenarios.

In a first scenario (628), no positive reply has been received from the worker device 106n at the top of the queue (e.g. for queue 450, worker A has not replied to the offer). In this scenario 628, if the job has not been assigned to a worker and the time elapsed since the job offer was submitted to the first worker is greater than Ta (630), then the job offer is sent to the next worker in the queue (e.g. for queue 450, the job offer is sent to worker B).

This step 630 is repeated for each worker (the repeated steps are not shown in FIG. 5B). For example, once the job offer has been sent to the second worker, if the job has not been assigned to a worker, and the time elapsed since the job offer was submitted to the second worker is greater than Tb, then the job offer is sent to the next worker in the queue (e.g. for queue 450, the job offer is sent to worker C). This process continues as the job offer is sent consecutively to the next worker in the queue. The times Ta, Tb and so on are not necessarily the same value and in some embodiments are determined by various factors such as whether the workers are priority or non-priority, and the scores given to the workers by the matching algorithm. The calculation of these values is described in further detail herein.

Furthermore, if the time left until the start time of the job is less than a first predetermined amount Ti (632), the server 102 sends a notification to the manager device 104 to notify the manager that there still hasn’t been a worker assigned with the time left until the job being Ti.

If further time has elapsed and the time until the start time of the job Tj_Ob is less than a second predetermined amount T2 (634), the server 102 sends a second, more urgent notification to the manager device 104 to notify the manager that there still hasn’t been a worker assigned, with the time left until the job being T2.

If yet further time has elapsed and the time until the start time of the job Tj_Ob is less than a third predetermined amount T3 (636), then the job offering process is cancelled, and the server 102 notifies the client device and/or next-of-kin device that a worker could not be found for the job. Optionally, the server 102 also sends a notification to the manager device 104 that the job request was unsuccessful.

The times between transmitting the job offer to the first worker in the queue and the second worker in the queue Ta, and the second and the third in the queue Tb, and so on, take different values for different embodiments of the invention.

In some embodiments, if the next worker in the queue is a priority worker then the time between transmitting the job offer to the previous worker and the next worker in the queue is a first time, Tp. In some embodiments, the value of Tp is 1 hour. If the next worker in the queue is a nonpriority worker then the time between transmitting the job offer to the previous worker and the next worker in the queue is a second time, Tnp, wherein Tnp is greater than Tp. In some embodiments, the value of Tnp is 2 hours.

In other embodiments, the time between transmitting the job offer to the previous worker and the next worker in the queue is based on several characteristics of one or both of the relevant worker profiles. If the time between transmitting the job offer to worker (i-1) (i.e. the previous worker in the queue) and worker (i) (i.e. the next worker in the queue) is denoted by Ti, then in some embodiments Ti is equal to the average response time of the previous worker to previous job offers (which the server 102 saves and updates in the worker profile log 114). In other embodiments, Ti is equal to the average response time of the previous worker to previous job offers that are transmitted to the worker in a given period of the day. This gives a more accurate picture of the responsiveness due to filtering out job offers which were transmitted overnight, for example.

In some embodiments, Ti is proportional to the difference in matching scores of the previous worker and the next worker as calculated by the matching algorithm. In other words, if the score differential is minimal, the length of time between the workers is shorter; if the score differential between the workers is large, then the time could be longer. In these embodiments the system gives more time to workers with a distinctive high matching score compared to competing workers in order to maximise the possibility of allocating the job to the best-matched worker.

In a particular embodiment, the time Tris calculated by the formula:

Ti = AvgRi-y +)5(1 + Δ5) + Si

Where AvgRj-i is the average response time of worker (z-7) based on the worker profile saved in the worker profile log 114; β is equal to a multiplication factor; AS is equal to the difference in matching scores between worker (z-7) and worker (z); and Si is equal to a fixed time increment if worker (z-7) is busy at the time the job offer was sent to them (for example if they are currently working on another job or if the worker device is offline). The term )5(1 + Δ5) can be denoted as Ai and can be considered a score differential factor. The skilled person will appreciate that the multiplication factor can take many values depending on the scoring system used and the time scales of the job offers. In an example, AS is calculated using a value for β of 3, and using the difference in score as measured in percentage points. For instance, if the previous worker has a matching score of 90% and the next worker has a matching score of 80%, and the time is measured in minutes, then the score differential factor would result in an additional 30 minutes waiting time.

In some embodiments that utilise the above formula, the server 102 is also restricted by the requirement that there is a minimum amount of “residual” time left at the end of the job offering process to be able to re-allocate the visit, if no workers have accepted the offer (for example by generating a new queue). This residual period can be set by the manager device 104. In some embodiments, the residual time is calculated so that the delivery queue expires if a worker is not allocated by a predetermined time the day before the job is scheduled to begin.

In some embodiments, the server 102 calculates the times Tiand enforces the residual time requirement by scaling the times Ti proportionally, so that a sufficient residual time is met. In other embodiments, the times Ti are capped at a maximum value to meet the residual time constraint.

In a second scenario 638, a worker replies to decline the job offer. The server 102 replies to the worker device 106n to acknowledge the reply. If there are more workers in the queue that have yet to reply to the job offer (640), then the server awaits the replies and the job offer remains pending (i.e. awaiting a worker to assign the job to). If the server is awaiting no further replies, but there are still remaining workers in the queue that have not received the job offer, the server transmits the job offer to the next worker in the queue. If there are no more workers in the queue that have not replied - i.e. all workers have replied declining the job offer (642), then the server 102 sends a notification to the manager device 104 that all workers have declined the job offer. The manager is then able to generate a queue of new workers or contact the workers directly to try to re-negotiate the job offer, in order to successfully assign the job to a worker.

In a third scenario 644, a worker replies using the worker device 106n to accept the job offer. If the worker is marked as a priority worker (646) and the job has not already been assigned, then the job is assigned to that worker and the server 102 updates the relevant information in memory 112. The worker device 106n is sent a notification from the server that it has successful been assigned the job, and the client device 108 is sent a notification that a worker has been assigned the job. The worker is then able to access further information about the job through the portal 110, and the client is able to access information about the worker that has been assigned the job. Optionally, the manager device 104 is also sent a notification that the work device 106n has been assigned the job. The job offer process is also terminated for the other worker devices 106n (for example, a notification is sent to the remaining worker devices that the job has now been assigned, or the job offer is retracted by the server).

If the worker accepting the job is marked as a non-priority worker (648) and there are workers higher up in the queue that have not responded (650), then the job offer remains open to the other workers, and a time-out period is triggered. The worker’s acceptance is acknowledged by the server 102 and the worker is notified that they will be alerted if they are assigned the job after the time-out period has elapsed. Once the time-out period has elapsed (654), the highest worker in the queue that has accepted the job is assigned the job, and all other workers that had accepted the job are notified that they were not successfully assigned the job. The skilled person will appreciate that the time-out period can take any value depending on the nature of the job requested. In some embodiments the time-out period is 2 hours.

If the worker accepting the job is marked as a non-priority worker (648) and all workers higher in the queue have already declined the job offer (652), then the job is assigned to the non-priority worker and the server 102 updates the relevant information in memory 112. The worker device 106n is sent a notification from the server that it has successful been assigned the job, and the client device 108 is sent a notification that a worker has been assigned the job. The worker is then able to access further information about the job through the portal 110, and the client is able to access information about the worker that has been assigned the job. Optionally, the manager device 104 is also sent a notification that the work device 106n has been assigned the job.

If a worker replies to accept the job offer but the job has already been assigned (656), then the server 102 notifies the worker via the worker device 106n that the job has been assigned and is no longer available.

Duplicate replies

Whether the value of Tj_Ob - T_req is less than or grater than the predetermined “urgency” threshold, the server 102 may receive a second reply from a worker device that has already replied to the job offer (658).

In a first scenario, a worker that initially declined the job offer later accepts it (660). In this case, if the job has already been assigned then the worker is notified by the server 102 that this is the case. If the job has not yet been assigned then the decision tree algorithm (600) applies the corresponding process as if it were the worker’s first reply. Optionally, in the case where the j ob offer has been terminated because no workers replied in time (612, 636), the server 102 may notify the manager device 104 so that the manager can communicate with the worker and client in order to successfully assign the job within the limited time left until the job start time.

In a second scenario, a worker that initially accepted the job offer later declines it (662). If the job was already assigned to a different worker anyway, then the worker is notified that they are not assigned the job. If the worker is assigned the job, the server 102 notifies the worker that they have been assigned the job, and directs them to contact the manager to re-assign the job. The manager is also notified via the manager device 104.

In a third scenario, a worker repeats their first reply - i.e. a worker that has declined the job offer declines the job a second time (664). In this case the server 102 sends a notification to the worker that they have already accepted or declined the offer.

FIG. 6A illustrates a group broadcast message according to an embodiment of the invention. In FIG. 6A, a job request has been received at the server 102 at a time T_req, for a job starting at Tj_Ob, from client device 108. The server calculates the value of Tj_Ob - T_req which is found to be less than a threshold value. The server 102 therefore broadcasts a job offer to all compatible worker devices at once, indicated by the arrows labelled “O” from “OFFER” to the worker device A-E. A first worker replies “NO” to the offer, i.e. declines the offer (shown by the arrow labelled “a”). The server acknowledges the reply from worker device A (not shown). As there are still more workers in the queue which have not replied to the job offer, the server 102 keeps the job offer open and does not terminate the offer. A second worker device C then replies “YES” to the offer, i.e. accepts the offer (shown by the arrow labelled “c”). As the job has not yet been assigned, the server 102 assigns the job to worker device C and updates the relevant information in the memory 112 of the server. The worker device C is sent a notification from the server that it has successful been assigned the job, and the client device 108 is sent a notification that a worker has been assigned the job. The worker is then able to access further information about the job through the portal 110, and the client is able to access information about the worker that has been assigned the job. Optionally, the manager device 104 is also sent a notification that the work device 106n has been assigned the job. Next, a worker device E replies “YES” to the offer i.e. accepts the offer (shown by the arrow labelled “e”). The server 102 has already assigned the job to the worker device C, and so the server 102 notifies the worker device C that the job has been assigned and is no longer available. This may happen, for example, when the worker device C replies to the offer before the job offer process is terminated by the server 102 (for example, before a notification is sent to the remaining worker devices that the job has now been assigned).

FIG. 6B illustrates a cascaded broadcast message according to an embodiment of the invention. In this case, a job request has been received at the server 102 at a time T_req, for a job starting at Tjob, from client device 108. The server calculates the value of Tj_Ob - T_req which is found to be greater than a threshold value. The server 102 therefore retrieves a queue of worker devices generated from a matching algorithm. The queue of worker devices is received as: Ap, Bp, Cp, D,

E. Worker devices A-C are marked as priority workers, denoted by the subscript P, and worker devices D and E are marked as non-priority workers.

The server therefore transmits a job offer to the highest worker device in the queue, worker device Ap, which is indicated by the arrow labelled Oi in FIG. 6B. After a time Tab elapses, worker device Ap has still not replied to the job offer. As a result the server 102 transmits the job offer to the next highest worker device in the queue, which is worker device Bp, indicated by the arrow O2. A further time Tbc elapsed, and neither worker devices Ap or Bp reply to the job offer. The server 102 therefore sends the job offer to the next highest worker in the queue, Cp, indicated by the arrow O3. After a time Tcd elapses, none of the worker devices Ap-Cp have replied to the job offer. Therefore, the server transmits the job offer to worker device D, indicated by the arrow O4.

Before a time Tde elapses, worker device D replies “YES”, i.e. accepts the job offer, indicated by arrow Ai. As the worker device D is a non-priority worker device, and there are priority worker devices that have still not replied, the server 102 acknowledges the reply from device D (not shown) and a time-out period is triggered. The worker device D is notified that they will be alerted if they are assigned the job after the time-out period has elapsed. Within the time-out period, worker device Cp replies “YES”, i.e. accepts the job offer, indicated by arrow A2. As the worker device Cp is a priority device, the server 102 assigns the job to device Cp and updates the relevant information in the memory 112. Worker device D is informed that their acceptance was not successful. After the job is assigned, worker device Bp replies “YES”, i.e. accepts the job offer, indicated by arrow A3. As the job has already been assigned, the server 102 notifies the worker device Bp that the job has been assigned and is no longer available.

As highlighted in the examples shown in FIG. 6A and FIG. 6B, the server 102 takes into account the urgency of the job request, in order to broadcast a job offer to many devices at once where the job needs to be assigned urgently. The server also take into account less urgent situations where there is sufficient time to send the job offer more efficiently. In the case highlighted in FIG. 6B, the job offer is only broadcast to devices A-D, meaning a more efficient and optimal job offering process (i.e. one which leads to a higher proportion of acceptances which actually result in an assigned job). As also highlighted in FIG. 6B, the job offer process increases the likelihood that a well-matched worker will be assigned a given job.

Whilst in the embodiments described above the server 102 performs a matching algorithm to generate a queue of workers, and later performs a job offer delivery algorithm based on the queue of workers, optionally the server 102 also performs periodic availability checks. For instance, at defined intervals the server 102 checks whether the workers in the queue are still available for the job. In particular, in one embodiment the server 102 checks the availability of a worker a time interval before the job offer is scheduled to be sent to the worker. For instance, if a worker is in a worker queue for a first job, and in some intervening time period accepts a second job which clashes with the first job, then when the server 102 checks the availability of the worker it will find that the worker is no longer compatible for the first job. In another example, the worker may accept a job which does not clash with the first job, but the location of the job may make it impossible or unlikely that the worker is able to reach the location of the first job in time. As a result, the worker will be removed from the queue and the queue will be updated so that a job offer is not sent to an incompatible worker. The job offer delivery algorithm performs as outlined above, using the updated queue that the server 102 generates.

The server 102 may optionally be configured to send periodic reminders to the worker devices 106n. For example, the server 102 may send a weekly reminder to all workers regarding the upcoming jobs they have been assigned for the coming week. The server 102 may further send reminders to each worker a pre-determined time interval before a job is due to start. For example, the server 102 may send a reminder to workers two days before a job is due to start. The reminders may also include a reminder to contact the manager device 104 if the worker can no longer make the job.

The worker assigned a job may need to later cancel the job after it has been assigned. Where the worker cancels the job assignment, the server 102 creates another list of compatible workers according to the matching algorithm described above and delivers job offers to workers according to the delivery algorithm described above.

If the client or next-of-kin cancels the job, then the server 102 updates the relevant information in the memory 112 and sends a notification to the assigned worker that the job is cancelled.

The client, next-of-kin or manager may edit the job details as necessary. If the job details are edited then the server 102 updates the relevant information an sends a notification to the assigned worker that the job details have been updated.

When a job is due to start, the worker is able to update their worker profile status (i.e. by changing their status to an “on my way” status). This status can be updated via the worker device 106n and the server updates the worker profile log 114 accordingly. The client device 109 and/or next-of-kin device and the manager device 104 are able to view the new status of the worker profile.

When the worker arrives at the job, the worker checks in to the job. Any known verification process can be used. In some embodiments the worker uses the worker device 106n to check in (for instance by matching the location of the worker device 106n to the location of the client device 108 or the next-of-kin device 109). In other embodiments the worker calls a specific number on the client’s landline or mobile device to verify the check-in.

When the worker completes any specific tasks, the worker can update the job details via the worker device 106n to check off completed tasks. The server 102 then updates the relevant information so that the client device 108 and/or the next of kin device 109 can monitor the progress of work. Once the job is completed, for instance once the tasks are completed or once the job time has elapsed, the worker can check out of the job using the worker device 106n. The server 102 then updates the relevant information saved in the memory 112 and marks the job as completed.

Certain variants to the described invention will be apparent to the skilled person. For example, the devices referred to with respect to FIG. 1 may be smartphone devices, tablets or PCs. The web portal 110 may be accessed through a software application or a web browser. It will also be appreciated by the skilled person that any of the notifications sent or received by the server 102 as disclosed herein could be by any means, and include SMS messaging, emailing and software application notifications.

It should be emphasized that the server shown in Figure 1 is exemplary and several different implementations and configurations of the server 102 are contemplated, which perform the same functions as the server shows in Figure 1.

The communications interface of the server 102 can be used to allow software and data to be transferred between the server 102 and external devices 104, 106n, 108 and 109. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium. The portal 110 may be a web portal.

It will be appreciated that the teachings of one embodiment described with reference to one Figure could be combined with the teachings of other embodiments.

The server 102 can also include a main memory, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by a processor. Such a main memory also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The server may likewise include a read only memory (ROM) or other static storage device for storing static information and instructions for a processor.

The server may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RW), or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.

In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the server. Such components may include, for example, a removable storage unit and an interface, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.

In this document, the terms ‘computer program product’, ‘computer-readable medium’ and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the server to cause the processor to perform specified operations. Such instructions, generally referred to as ‘computer program code’ (which may be grouped in the form of computer programs or other groupings), when executed, enable the server to perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.

In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the server using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code), when executed by the processor in the server, causes a processor to perform the functions of the invention as described herein.

It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organisation.

Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as FPGA devices. Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention.

Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.

Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to ‘a’, ‘an’, ‘first’, ‘second’, etc. do not preclude a plurality.

Claims

1. A computer-implemented method of delivering a job offer to a set of remote workers, comprising the steps of:

receiving a job request having a start time;

generating a set of workers that are compatible with the job request;

receiving a profile of each of the workers;

generating a matching score for each worker in the list, by comparing the profile of each worker to the j ob request, the score indicative of the suitability of each worker to the j ob; transmitting a job offer to a first worker device of the best-scoring worker;

if the best-scoring worker accepts the job offer within a first interval, assigning the job to the best-scoring worker;

if the best-scoring worker declines the job or does not reply within a first interval, transmitting the job offer to a second worker device of the next best-scoring worker; and if the job is not accepted by any worker within a second interval, transmitting the job offer to a third worker device the next best-scoring worker;

such that each interval is calculated based on at least one characteristic of at least one worker profile.

2. A computer-implemented method according to claim 1, wherein following the step of generating a set of workers that are compatible with the job request, the method comprises the steps of:

calculating the time difference between the time of receiving the job request and the start time;

if the time difference is less than a predetermined threshold:

broadcasting a job offer to a plurality worker devices of compatible workers; and assigning the job to the worker of the first worker device to accept the job offer; and if the time difference is greater than the predetermined threshold, performing the subsequent steps of claim 1.

3. A computer-implemented method according to claim 1 or 2, wherein each interval is based on a matching score differential between the most recently propositioned worker and the next bestscoring worker, the interval being higher for higher matching score differentials.

4. A computer-implemented method according to any preceding claim, wherein each interval is based on an average response time of the most recently propositioned worker device.

5. A computer-implemented method according to any preceding claim, wherein each worker device is marked as priority or non-priority.

6. A computer-implemented method according to claim 5, wherein each interval is based on whether the most recently propositioned worker device is marked priority or non-priority.

7. The computer-implemented method according to claim 5 or 6, wherein if the job is first accepted by a priority worker device, assigning the job to that priority worker device.

8. The computer-implemented method according to claim 7, wherein if the job offer is accepted by a non-priority worker device:

if the job offer has been sent to at least one priority worker device and the at least one priority worker device has not replied to the job offer:

waiting for a predetermined time period; and at the end of the predetermined time period, assigning the job to the worker device of the bestscoring worker whose worker device has accepted the job offer.

9. A computer-implemented method according to any preceding claim, wherein each interval depends on whether the matching score of the most recently propositioned worker is indicative of a better suitability than a threshold matching score.

10. A computer-implemented method according to any preceding claim, wherein each interval is increased by a predetermined amount if the worker profile of the most recently propositioned worker device indicates that the worker is busy or the worker device is offline.

11. A computer-implemented method according to any preceding claim, wherein the job offer terminates if the job offer is not assigned to a worker by a predetermined time period before the start time of the job.

12. A server for delivering a job offer to a set of remote workers, the server being configured to:

receive a job request having a start time;

generate a set of workers that are compatible with the job request;

receive a profile of each of the workers;

generate a matching score for each worker in the list, by comparing the profile of each worker to the job request, the score indicative of the suitability of each worker to the job;

transmit a job offer to a first worker device of the best-scoring worker;

if the best-scoring worker accepts the job offer within a first interval, assign the job to the bestscoring worker;

if the best-scoring worker declines the job or does not reply within a first interval, transmit the job offer to a second worker device of the next best-scoring worker; and if the job is not accepted by any worker within a second interval, transmit the job offer to a third worker device of the next best-scoring worker;

5

13. A computer program product configured to perform the method according to any one of claims 1 to 11.