WO2006122582A1

WO2006122582A1 - Method and system for exchanging a finite activity assigned to user with another user

Info

Publication number: WO2006122582A1
Application number: PCT/EP2005/052288
Authority: WO
Inventors: Jorge MÉNDEZ-BENEGASSI SILVA
Original assignee: Mendez-Benegassi Silva Jorge
Priority date: 2005-05-18
Filing date: 2005-05-18
Publication date: 2006-11-23
Also published as: WO2006122582A8

Abstract

A method for exchanging a finite activity assigned to a first user with at least a second user from a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, the method comprising the steps of Identifying the first user; capturing the data relating to the assigned finite activity of the first user; capturing at least one finite activity desired by the first user; searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user, according to the data stored in the repository; capturing the selected option of exchange among the at least one option; bringing together the first user and the second user involved in the selected option; validating the exchange between the first user and the second user.

Description

Method and system for exchanging a finite activity assigned to a user with another user

The present invention relates to a method for exchanging a finite activity assigned to a user with another user. More specifically, the invention relates to a method for exchanging a finite activity, such as a work shift, a period of vacations or an appointment, assigned to a user with at least another user.

Further, the invention relates to a system for exchanging a finite activity assigned to a user with another user, and a computer program for executing the method.

BACKGROUND ART

Nowadays, because of the existent overcrowding in different scopes of life, in a person's life there are outlined many situations where finite activities are assigned to carry out certain actions. Thus, at a professional level, finite activities such as work shifts or periods of vacations are assigned, while at a personal level finite activities such as systems of appointments for medical or similar consultations or of appointments in a certain administration (Treasury, Employment, Traffic, etc.) or a tee-time to play golf or tennis are assigned.

On the other hand, lately, the companies that have shift workers try to look for solutions to combat the stress and the fatigue of their employees, caused mainly by the disorder in the rest. Among the agents of the departments of health, security in the work and human resources, there is a growing interest in trying to keep a strong, healthy and happy staff in order to increase its productivity, to reduce the industrial working accidents, and to fulfill the requirements that many legislations establish regarding health and security at work. But the problem appears when people want to change the assigned finite activity (e.g., to change the date and/or the hour of a medical appointment, to change a work shift or a watch, or to change the period of vacations), for example, due to different assigned finite activities that are overlapped, for illness, or simply for the daily occupation of people.

At present, the well-known methods to carry out said changes are based on simple notice boards or static announcements in computer support (web pages, mailing lists, etc.), through which a person can change his/her assignment for the assignment of another person, that is, people can exchange their assigned finite activities. In some cases, there is also the possibility of carrying out, in certain cases (e.g., to change a medical appointment), telephone calls to get the change of the assignment, although in this case the exchange will never be carried out with another person, but the following available finite activity will be assigned to the person, that can be very distant in time.

In the case of notice boards, it is necessary to search, often in different locations, among an enormous quantity of paper notices, without placement order, and/or addressed to different groups outside his/her interest, the bids of change that are adapted to his/her requirements. Further, the person must annotate these bids or to hang his/her bids in a visible place, without knowing, for example, the times that the message has been read, or if the message has been covered or eliminated by another person.

In the case of static announcements in computer support, the bids of change usually go under a brief title or link that it does not give enough information to determine if it is a convenient bid, or if it is addressed to a group of people that coincides with a group of his/her interest, until the link is opened and the rest of text is read. Since this process should be repeated several times until locating, if it exists, the wanted bid, and keeping in mind the even present limitations in the speed of transmission of data, the process of looking for a change becomes complicated and laborious.

Also, it is possible that the selected bid is no longer effective, for example, because the person of the bid has previously been able to carry out the wanted assignment change. Especially in the case of notice boards, maintenance of the bids does not exist, and, therefore, the satisfied bids of change are not eliminated.

On the other hand, according to the chosen method, it is necessary that the contact data and the bids are visible all over the world, with what is putting on in danger the intimacy and the privacy of people.

Consequently, the well-known methods are slow, unsure and untrustworthy.

DISCLOSURE OF THE INVENTION

It is therefore an object of the invention to provide a method which solves the problem of automatically exchanging a finite activity assigned to a user with at least another user. The finite activity relates to, for example, a work shift, a period of vacations, or an appointment (medical, etc.).

According to a first aspect, the invention provides a method for exchanging a finite activity assigned to a first user with at least a second user from a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, the method comprising the steps of (A) identifying the first user; (B) capturing the data relating to the assigned finite activity of the first user; (C) capturing at least one finite activity desired by the first user; (D) searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user, according to the data stored in the repository; (E) capturing the selected option of exchange among the at least one option; (F) bringing together the first user and the second user involved in the selected option; and (G) validating the exchange between the first user and the second user.

Consequently, a method for exchanging a finite activity assigned to a first user with at least a second user, in an organized, quick and automatic way is achieved. Further, the privacy is kept safe and the method search among multiple options and it brings together, in an automatic way, the users involved in the possible exchange. On the other hand, the method allows exchanging a finite activity between more than two users, which is not possible with the known methods of the state of the art, especially when users specify more than one desired option and the search explores through all possible solutions. This is a problem that grows exponentially.

In the case of a company, the method can provide valuable data to the department of human resources, about the preferences of the staff with reference to the schedule and the working periods that the staff wishes. With this knowledge, the company can increase the satisfaction of the staff and consequently the yield of the company.

Preferably, the method can comprise a step (H) of registering the first user in the repository. This step can comprise the sub-steps of (H.1) capturing the personal data of the first user; (H.2) capturing at least one selecting parameter for relating the first user to an adequate group of users; and (H.3) storing the personal data and the selecting parameter of the first user in the repository.

In this way, the search of options for exchanging the assigned finite activity of the first user with the second user is only performed on the group of user with the same assigned selecting parameter that the first user. For instance, in the case of a company (period of vacations, work shifts, etc.), the search must be performed on the group of users of the same company and the same job, whereas, in the case of a medical appointment, the search must be performed on the group of user with the same assigned doctor. In this case, it can be very important to combine the data stored in the repository of users with the schedule of the doctor.

A step (I) of activating the first user, between the step (H) of registering the first user and step (A) of identifying the first user, can be included. The purpose of this step is to verify, for the first time, that the email and mobile phone number really belongs to the user trying to join the system, to check the capability of the user to receive messages from the system and it also provides a more secure identification.

In one embodiment, step (D) comprises the sub-steps of (D.1) searching for the second user with an assigned finite activity equal to a -desired finite activities of the first user; (D.2) verifying if the second user is detected, if no results the control goes to sub-step (D.8); (D.3) verifying if a desired finite activity of the second user is equal to an assigned finite activity of the first user, in the case of positive verification, passing the control to sub-step (D.7a); (D.4) searching for a third user with an assigned finite activity equal to a desired finite activity of the second user; (D.5) verifying if the third user is detected, if no results the control returns to sub-step (D.1); (D.6) verifying if a desired finite activity of the third user is equal to an assigned finite activity of the first user, in the case of negative verification, passing the control to sub-step (D.4); (D.7) storing the positive combination of three users as an option to exchange and returning the control to sub-step (D.1); (D.7a) storing the positive combination of two users as an option to exchange and returning the control to sub-step (D.1); (D.8) verifying if at least one option is determined; (D.9) in the case of negative verification, waiting for a new entry; (D.10) in the case of positive verification, appointing the options; (D.11) verifying if an option is selected.

Firstly, in another embodiment of the invention, direct exchanges can be searched (i.e., exchanges between two users). Later, exchanges between three (user A wants something that user B offers; user B wants something that user C offers; user C wants something that user A offers) or more users can be searched. For example, in the case of four users: user A wants something that user B offers, user B wants something that user C offers, user C wants something that user D offers, and user D wants something that user

A offers. Each located exchange is an option for exchanging the assigned finite activity with the at least second user, one of which must be selected.

In the case of that a direct exchange is the selected option, step (F) can comprise sub-steps of (F.1) sending the personal data of the first user to the second user; (F.2) contacting the first user and the second user by means of the provided personal data.

In the case of that an exchange between three users is the selected option, step (F) can comprise sub-steps of (F.1) sending the personal data of the first user and the second user to the third user; (F.2) sending the personal data of the first user and the third user to the second user; (F.3) contacting the first user, the second user and the third user by means of the provided personal data.

If the selected option involves four users, step (F) can comprise sub-steps of sending the data of the first, third and fourth to the second user; sending the personal data of the first, second and fourth to the third user; sending the data of the first, second and third to the fourth user; contacting the first, second, third and fourth users by means of the provided personal data. Said described configuration is appropriate to increase privacy of the process in case of a malicious first user. The second user will contact the first one.

In anyone of the cited cases, the method brings together all users involved in the exchange. From the stored data of users in the repository, each user automatically receives, for example, an email and a SMS with the bid and personal data of the user or users involved in the exchange. Until this moment, the personal data of users have been kept secret, and only can be viewed by the users involved in the exchange. In this way, the privacy is guaranteed.

If there is no at least one option to exchange, the user can wait until another user offers an adequate bid. Also, the user can consult his/her bid or bids and the bids of the users of the same group of users to find and adequate bid. The user is allowed to delete his previous bid and raise a new one in order to adequate his preferences so as to fit in one bid of other user.

According to another aspect, the present invention provides a system for exchanging a finite activity assigned to a first user with at least a second user comprising a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, and further comprising means for identifying the first user; means for capturing the data relating to an assigned finite activity of the first user; means for capturing at least one finite activity desired by the first user; means for searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user, according to the data stored in the repository; means for capturing the selected option among the at least one option; means for bringing together the first user and the second user; and means for validating the exchange between the first user and the second user. According to yet another aspect of the invention there is provided a computer program comprising program instructions for causing a computer to perform the method according to the invention.

Because the invention can work in a multi-user client/server environment such as, for example, the internet network, independent claims to the individual methods performed on the individual stations of the network are provided. A claim which recites the processing of data on a client computer system and the transmission of data to a server computer system is provided as follows.

According to yet another aspect, the present invention provides a method for selecting an exchange option of a finite activity assigned to a first user with at least a second user, comprising the steps of (S1 ) capturing identification data of the first user; (S2) sending the captured identification data to a remote computer system for identifying the first user; (S3) capturing the data relating to the assigned finite activity of the first user and at least one finite activity desired by the first user; (S4) sending the data captured in step (S3) to the remote computer system for determining at least one option of exchange; (S5) receiving the at least one option for exchanging the assigned finite activity of the first user with the second user according to the data sent in step (E); (S6) capturing the selected option of exchange among the received at least one option; (S7) validating the exchange between the first user and the second user.

Further, the method can comprise the steps before step (S1 ) of (S8) capturing registration data of the first user; (S9) sending the captured registration data to the remote computer system for registering the first user. Step (S8) of capturing registration data of the first user can comprise the sub-steps of (S8.1 ) capturing personal data of the first user; (S8.2) capturing at least one selecting parameter for relating the first user to an adequate group of users.

Step (S8) can also comprise the sub-steps of (S8.3) capturing an answer of the first user to at least one filtering question with reference to the assigned group of users; (S8.4) Sending the answer to the remote computer system to verify it.

Furthermore, the method can comprise the steps after step (S8) of (S10) capturing activation data of the first user; (S11) sending the captured activation data to the remote computer system to activate the first user.

According to another aspect of the invention, there is provided a computer system for selecting an exchange option of a finite activity assigned to a first user with at least a second user comprising._^ means for capturing identification data of the first user; means for sending the captured identification data to a remote computer system for identifying the first user; means for capturing the data relating to the assigned finite activity of the first user and at least one finite activity desired by the first user; means for sending the captured data to the remote computer system for determining at least one option of exchange; means for receiving the at least one option for exchanging the assigned finite activity of the first user with the second user according to the sent data; means for capturing the selected option of exchange among the received at least one option; means for validating the exchange between the first user and the second user.

A claim which recites the processing of data on a server computer system and the transmission of data to a client computer system described above is provided as follows. According to yet another aspect, the present invention provides a method for exchanging a finite activity assigned to a first user with at least a second user from a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, the method comprising the steps of (T1) receiving identification data of the first user from a remote computer system; (T2) identifying the first user from the received data; (T3) receiving data regarding to the assigned finite activity of the first user and at least one finite activity desired by the first user from the remote computer system; (T4) searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user according to the data received in step (T3); (T5) sending the at least one option to the remote computer system; (T6) receiving the option selected among the at least one option from the remote computer system; (T7) bringing together the first user and the second user involved in the selected option; (T8) validating the exchange between the first user and the second user.

The method can also comprise the steps before step (T1) of (T9) receiving registration data of the first user from the remote computer system; (T10) registering the first user in the repository by means of the received registration data.

Further, step (T9) of receiving registration data of the first user can comprise sub-steps of (T9.1) receiving personal data of the first user; (T9.2) receiving at least one selecting parameter for relating the first user to an adequate group of users.

Step (T9) can also comprise sub-steps of (T9.3) receiving an answer of the first user to at least one filtering question with reference to the assigned group of users from the remote computer system; (T9.4) verifying the answer of the first user.

Further, the method can comprise the steps after step (T9) of (T11) receiving activation data of the first user from the remote computer system; (T12) activating the first user in the repository by means of the received activation data.

According to yet another aspect of the invention, there is provided a computer system for exchanging a finite activity assigned to a first user with at least a second user comprising a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, the computer system also comprising means for receiving identification data of the first user from a remote computer system; means for identifying the first user from the received data; means for receiving data regarding to the assigned finite activity of the first user and at least one finite activity desired by the first user from the remote computer system; means for searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user according to the received data; means for sending the at least one option to the remote computer system; means for receiving the option selected among the at least one option from the remote computer system; means for bringing together the first user and the second user involved in the selected option; means for validating the exchange between the first user and the second user.

According to another aspect, the invention provides a computer program comprising program instructions for causing a computer to perform the method described above. BRIEF DESCRIPTION OF THE DRAWINGS

In the following detailed portion of the present description, the invention will be explained in more detail with reference to the exemplary embodiments shown in the drawings, in which:

Fig.1 is a flow chart illustrating the method for exchanging a finite activity assigned to a user with at least another user in accordance with the present invention; Fig.2 is a flow chart illustrating the sub-steps of the registering step (H) of the method of Fig.1 ;

Fig.3 is a flow chart illustrating the sub-steps of the activating step (I) of the method of Fig.1;

Fig.4 is a flow chart illustrating an embodiment of the searching step (D) of the method of Fig.1 ;

Fig.5 is a flow chart illustrating an alternative embodiment of the searching step (D) of. the method of Fig.1 ;

Fig.6 is a graphical representation of the "Possible work shift options" as viewed on a computer screen for the present invention; Fig.7 is a graphical representation of a "user bid for a non-shift based work" as viewed on a computer screen for the present invention;

Fig. 8 is a graphical representation of a "user bid for a shift-based work" as viewed on a computer screen for the present invention;

Fig.9 is a graphical representation of a "pairing number of a flight" as viewed on a computer screen for the present invention;

Fig.10 is a graphical representation of a "three day pairing flight" as viewed on a computer screen for the present invention;

Fig.11 is a graphical representation of "what the user wants on exchange" as viewed on a computer screen for the present invention; Fig.12 is a graphical representation of a "period of vacation exchange

(fortnight)" as viewed on a computer screen for the present invention; Fig.13 is a graphical representation of a "period of vacation exchange (week)" as viewed on a computer screen for the present invention; Fig.14 is an embodiment of the computer program according to the invention for executing the method of the Fig. 1 ; Fig.15 is an schematic diagram illustrating the two portions (Public/ Private) of the lnit Module of the computer program of Fig.14; and Fig.16 is an example of design of some database tables used in the invention.

DETAILED DESCRIPTION

In the following detailed description, embodiments of a method and a system for exchanging work shifts or periods of vacation assigned to a worker of a company with at least another worker according to the invention will be described. Obviously, the method with other types of finite activities and other groups of users could be described (medical appointments, etc.).

The present invention overcomes the problems in searching for changes of, for example, shifts or working days, guards and vacations among employees in the same company and who carry out the same work, in an organized and automatic way, preserving the intimacy and searching among multiple possibilities, automatically putting in contact the users involved in a possible change.

Furthermore, if launched in collaboration with the company, it may provide valuable information, to human resource departments, about the preferences of the employees on timetables or working periods desired to be carried out, and their satisfaction and therefore business performance are increased with that knowledge.

It is also of interest for the company to know which employees want to work certain days, shifts or guards or enjoy vacations in different periods, as they can therefore obtain a great flexibility when planning their resources, since it is easier to solve the "day-to-day" and to reduce the on-duty employees, incidents, reserves, etc. Asking an employee for a favour is not the same as biding her/him what they are interested in when, moreover, it is what the company is looking for.

Fig.1 is a flow chart illustrating a preferred embodiment of the method for exchanging work shifts or periods of vacation assigned to a worker with at least another worker (herein the finite activity will be a work shift). Starting from an idle status, when a worker wants to exchange a work shift, the worker must be registered (step H) and activated (step I) in a database (DB) of workers. Once the worker has been registered and activated, the worker must be identified (step A) to verify that exists in the database (DB), and to obtain the stored data. If the worker has not been identified, the control of the method returns to step (A). Next, the assigned work shift that the worker wants to exchange must be captured (step B), as well as (step C) at least one work shift desired by the worker, defining a bid. In that moment, the captured data associated to the worker can be stored in the database DB, but can be stored in any other appropriate time.

Next, an automatic search of options for exchanging the assigned work shift with at least another worker of the database (DB), from the data of each worker registered in the database, must be carried out (step D). Once at least one option has been found, the selected option must be captured (step E) and the workers involved in the exchange must be brought together (step F). Finally, the exchange must be validated (step G), for example, removing the bid from the database (DB).

Step (F) of bringing together the users depends on the number of user involved in the selected option. For example, in the case of two users, the personal data of the first user must be sent to the second user, for contacting the first user and the second user by means of the provided personal data.

In the case of three users, the personal data of the first user and the third user must be sent to the second user, the personal data of the first user and the second user must be send to the third user, for contacting the first user, the second user and the third user by means of the provided personal data.

Said configuration for sending the personal data can be modified whenever the confidentiality is guarantee.

Because the preferred embodiment of the invention is for use on the internet network, that is, in a multi-user client/server environment, individual methods performed on the client computer system and the server computer system must be described.

Firstly, the processing of data on tine client system and the transmission of the data to the server system will be described.

Thus, the client system must capture (step S8) the registration data of the first worker and send (step S9) said data to the server computer system for registering the first worker. Next, the activation data of the first worker must be captured (step S10) and sent (step 11) to the server system for the first worker to be activated. When the first worker has been activated, the identification data of said first worker must be captured (step S1) and sent (step S2) to the server system for the first worker to be identified. In the following stage, data relating to the assigned work shift of the first worker and the desired work shift by the first worker must be captured (step S3) and sent (step S4) to the server computer system for determining at least one option of exchange. Then the client computer system receives (step S5) the at least one option for exchanging the assigned work shift of the first worker with the second worker according to the data sent in step (S4) and captures the selected option of exchange. Next, the exchange must be validated (step S7), for example, capturing the deletion of the exchanged bid and sending said deletion to the server system for deleting the bid from the repository.

In step (S8), the client system can capture the personal data of the first worker (sub-step S8.1 ) and at least one selecting parameter (sub-step S8.2) for relating the first worker to an adequate group of worker, for example, according to a job. Further, the client system can capture (sub-step S8.3) an answer of the first worker to at least one filtering question with reference to said group of workers and send (sub-step S8.4) the answer to the server system for verifying it.

Obviously, for performing the cited steps, the client computer system must comprise means for capturing data (registration, activation, identification data, data relating to the assigned and desired work shifts and the selected option, etc.), means for sending said data to the server, and means for receiving data from the server. The means for capturing data may comprise graphic user interfaces with control elements (TextBox, CheckBox, ListBox, etc.) to enter the required data. Basically, all GUI can comprise a control element in the form of a button. When the first user acts on the button by means of a pointer device, such as a mouse, a control signal is generated to capture all data entered in the GUI and send said data to the server, for example, through internet (TCP-IP). GUIs can be created in the server and sent to the client system to be displayed.

On the other hand, the processing of data on the server system and the transmission of the data to the client system will be described.

The server system must receive (step T9) registration data of the first worker from the client computer system and register (step T10) the first worker in the repository of workers from the received data. Next, if the registration is correct, an activation code can be sent to the first worker (e.g. SMS to the mobile phone or/and an email to a computer) and the server receives (step T11 ) said code in the form of activation data for activating the worker in the repository. Once the worker is activated (step T12), the server must receive (step Tϊ) identification data of the first worker from the client system and identify (step T2) the first worker from the received data and the data stored in the repository. If the worker is identified, the server must receive (step T3) from the client system data regarding to the assigned and desired work shifts of the first worker. With said data, the server searches (step T4) automatically from the data of the repository at least one option for exchanging the assigned work shift of the first worker with the second worker and sends (step T5) to the client system the at least one option of exchange for one of said options is selected. Then, the selected option is received (step T6) by the server and the workers involved in the exchange are brought together (step T7). Once the exchange is performed, said exchange must be validated (step T8), for example, receiving a deletion data of the bid and deleting the bid from the repository.

It is important to highlight that the step (T7) can be performed in different ways, for example, according to the number of workers involved in the exchange or the security level desired for the invention.

Further, step (T9) of receiving registration data can comprise receiving (sub- step T9.1) personal data of the first worker, receiving (sub-step T9.2) at least one selecting parameter for relating the first user to the adequate group of users, and/or receiving (sub-step T9.3) the answer of the first user to the at least one filtering question with reference to the assigned group of user and verifying (sub-step T9.4) said answer from the data stored in the repository. Obviously, for performing the cited steps, the server computer system must comprise means for receiving data (registration, activation, identification data, data relating to the assigned and desired work shifts and the selected option, etc.), means for identifying the first user, means for searching automatically the at least one option of exchange, means for sending data (data regarding to the at least one option of exchange) to the client, means for bringing together the users involved in the exchange, and means for validating the exchange. In said preferred embodiment of the invention, the cited means can be implemented by a computer program, which will be described afterwards.

Clearly, a lot of steps of said described methods can agree with steps of the method described according to Fig.1. Although said steps can be referenced with different numerical references the steps can be coincident.

If a worker wishes to perform an exchange of a work shift, a working day, an appointment, etc, or to consult the bids performed by other workers, the worker must be registered. The worker must provide personal, company and job data. A user name, a password, an email address and a mobile phone number are essential.

As can be seen in the Fig. 2, step (H) of registering the worker in the database (DB) comprises the following sub-steps. Starting from an idle status, the personal data of the worker must be captured (sub-step H.1), which, for example, can comprise:

- Name of the worker

- Last Name

- Email

- Mobile - Username

- Password - Gender

Later, data related with the company and the job of the worker must be captured, which, for example, can comprise: - Company Name (to identify the company in the database DB)

- Country

- City

- State

- Job speciality, workstation, occupation or function of the worker in the company

- Workstation Schedule

Next, the Company Name is verified (sub-step H.6) to determine if exists in the database (DB), by means of a database query. In the case of the Company Name does not exist, similar Company Names with the same country and city are verified (sub-step H.7).

If a similar Company Name does not exist, a new record with the previous Company Name is opened (sub-step H.8), a new job speciality name is created and a selected work shift associated to the new job speciality is captured (sub-step H.9). Next, a filter questions (e.g., 2 or 3 questions that only people at job will know) are created (sub-step H.10), and a personal data and legal advice is appointed (sub-step H.11). The advice is verified (sub-step H.12), and if the advice is accepted, the data of the worker are registered (sub-step H.3) in the database (DB) and an activation code is sent to the email and mobile of the worker (sub-step H.14), whereas if the advice is not accepted, the step (H) of registering the worker is finished and the worker is not registered.

If similar Company Names exist, said similar Company Names are appointed (sub-step H.15), and they are verified (sub-step H.16) to find the Company among them. If the Company Name does not exist among the similar Company Names, the control goes to sub-step (H.8) and the following sub- steps described above. If the Company Name are in the similar Company Names, the company is captured (sub-step H.17) and the job specialities for the company are appointed (sub-step H.18). Said job specialities are verified (sub-step H.19) to determine if the speciality of the worker exists in the job specialities associated to the company. If the speciality of the worker does not exist, the control goes to the sub-step (H.9), and the following sub-steps described above.

If the speciality of the worker exists, the selected speciality is captured (sub- step H.20) and a database query is performed (sub-step H.21) by means of the Company Name, Country, City and Job Speciality, to obtain the work shifts associated to the selected speciality, which are appointed (sub-step H.22). The obtained work shifts are verified (sub-step H.23) to determine if the work shift of the worker exists so that if the work shift does not exist the control goes to sub-step (H.9) and the following sub-steps describe above, whereas if the work shift exists, the filter questions are captured (sub-step H.4) and verified (sub-step H.5). If the answers are correct, the control goes to sub-step (H.11) and the following sub-steps described above, whereas if answers are not correct, the control returns to sub-step (H.4) of capturing the filter questions.

In the case of the Company Name exists, the control goes to sub-step (H.18) and the following sub-steps described above.

After the worker gets the activation code, the worker must be activated (sub-step H.26), said activation code being verified to complete the register process (see Fig.3). The activation code received by the computer (email) and/or the activation code received by the mobile (SMS, MMS, etc.) are verified (sub-step H.27) with the username and password of the worker. If the activation code is correct, the worker is activated (sub-step H.28), whereas if the activation code is not correct, the number of tries is verified (sub-step H.29). If the number of tries is bigger than 3, the activation is not allowed, whereas if the number of tries is smaller or equal to 3, the control returns to sub-step (H.26).

Fig.4 is a flow chart illustrating the sub-steps of step (D) of searching (query) in the database DB at least one option to exchange the work shift assigned to the worker. After capturing the assigned work shift (step B) and the desired work shift (step C) of the worker, a search of a second worker with an assigned work shift equal to a desired work shift of the worker is performed (sub-step D.1). If a second worker is detected (sub-step D.2), the condition relating to if a desired work shift of the second worker is equal to an assigned work shift of the first worker is verified (sub-step D.3).

In the case of positive verification, the detected exchange option is stored (sub-step D.7a) and the control returns to sub-step (D.1), to detect another possible exchange options.

In the case of negative verification, a search for a third user (sub-step D.4) with an assigned work shift equal to a desired work shift of the second user is performed. If the search is unsuccessful the control returns to sub-step (D.1).

If a third user is found, sub-step (D.6) checks if a desired work shift of said third user is equal to an assigned work shift of the first user. In the case of positive verification, the detected exchange option is stored (sub-step D.7) and the control returns to sub-step (D.4) to find further users.

In the case of negative verification of sub-step (D.6) the control returns to sub-step (D.4) to find further users. When no more options exist (negative verification of sub-step (D.2)), the number of options is verified (sub-step D.8). If the number of options is equal to zero (options does not exist), the worker must wait (sub-step D.9) until an appropriate new bid is introduced. It is possible to send an alert (email, SMS, etc.) to the worker when said new bid is detected. If the number of options is bigger than zero, the options are appointed (sub-step D.10) and the option selected by the worker is verified (sub-step D.11). If an option is selected, the control goes to step (E) of capturing the selected option, whereas if an option is not selected, the method is ended (e.g. a selection from a user during a predetermined time period is waited).

In a first alternative embodiment of step D, in sub-step (D.1) the second worker must present a desired work shift equal to the assigned work shift of the first worker; in sub-step (D.3) if an assigned work shift of the second worker is equal to a desired work shift of the first worker must be verified; in sub-step (D.4) a third worker with a desired work shift equal to an assigned work shift of the second worker_* must be searched; and in sub-step (D.6) if an assigned work shift of the third worker is equal to a desired work shift of the first user must be verified.

Fig.5 shows another alternative embodiment of step (D). Firstly, all direct exchanges (i.e., exchanges between only two users) are detected (sub-step D.12). Later, all 3-side exchanges (i.e., exchanges between three users) are detected (sub-step D.13). Further, it is also possible to detect exchanges between four or more users. When all searches are performed, the detected options are verified (sub-step D.8). If no options are detected, the user must wait (sub-step D.9) an appropriate new bid for exchanging his/her assigned work shift, whereas if at least one option exists said option is appointed (sub-step D.10). Next, it is adequate to verify if an option is selected (sub- step D.11). In the case of positive result, the control goes to step (E) of capturing the selected option, whereas if an option is not selected, the method is ended (e.g. a selection from a user during a predetermined time period is waited).

In the preferred embodiment of the invention, the system for exchanging a work shift assigned to the first worker with the at least second worker comprises the database DB which stores, for each user (worker) of the system the assigned work shift and at least one desired work shift; means for registering the user in the database DB; means for activating the user in the system; means for identifying the user in the system; means for capturing the data relating to the assigned work shift of the first user; means for capturing the data relating to the desired work shift of the first user; means for searching automatically in the database DB at least one option for exchanging the assigned work shift of the first user with the second user; means for capturing the option selected by the first user among the at least one option; and means for validating the exchange between the first and the second users.

Basically, all means for capturing data (registering, activating, identifying, capturing) comprise generators of graphic user interfaces (GUI) in order to obtain data from the user. That is, by means of said interfaces, the users can introduce data in the system, and the system can capture them.

For example, Fig. 6 illustrates a graphic user interface 60 for selecting the appropriate work shift option among the shown possible work shift options. Said interface 60 is used in sub-step (H.9), during step (H) of registering the user in the database DB. Concretely, during the register process, the first user that registers a new company has to choose, from the graphic user interface 60 shown in Fig.6, the work shifts that are suitable to his/her job. Said selected work shifts will be applied to the next workers during their register process. In case the worker does not agree with the work shift options shown to the user by means of the interface 60, the worker can either input a new name for the job and indicate the correct work shifts or get in contact with the system administrator to solve the conflict.

The graphic user interface 60 comprises a group of option buttons 61,62,63,64,65, each of one represents a possible work shift option. The user can select the desired work shift option acting over the associated option button by means of a pointer device, such as a mouse. Acting over the control element "option button", the interface 60 generates a control signal to indicate the system which of the possible work shift options has been selected by the user. Clearly, the user inputs data that are captured by the system.

Fig. 7 shows a graphical user interface 70 for introducing a bid for exchanging an assigned finite activity that can be used in steps (B) and (C) of the method. Obviously, said interface 70 is not adequate to exchange a work shift because a work shift cannot be selected. In this case, the interface can be used in a system for exchanging, for example, a day of vacation.

The interface 70 comprises two parts: the first portion corresponds to the day that the user offers (the day assigned to the user) and the second portion corresponds to at least one day that user wants on exchange. In the first part, the interface 70 comprises a first control element 71 in the form of a ListBox for selecting the month of his/her assigned day of vacation and a second control element 72 in the form of a ListBox for selecting the day of his/her assigned day of vacation. When the user acts over the first control element 71 by means of the mouse, a control signal is generated to display all months of the year to the user, one of which is selected by means of the mouse for generating a control signal for determining the month selected by the user. When the user acts over the second control element 72 by means of a mouse, a control signal is generated to display all days of the previously selected month, one of which is selected by means of the mouse for generating a control signal for determining the day selected by the user. In this way the day of vacations offered by the user is created.

On the other hand, the second portion of the interface 70 comprises at least a first control element 73;75;77 in the form of a ListBox for selecting the month what the user wants on exchange and at least a second control element 74;76;78 in the form of a ListBox for selecting the day what the user wants on exchange. When the user acts over the first control element 73;75;77 by means of the mouse, a control signal is generated to display all month of the year to the user, one of which is selected by means of the mouse for generating a control signal for determining the month selected by the user. When the user acts over the second control element 74;76;78 by means of a mouse, a control signal is generated to display all days of the previously selected month, one of which is selected by means of the mouse for generating a control signal for determining the day selected by the user. In this way the day of vacations that the user wants on exchange is created.

As can be seen in Fig.7, the second portion comprises three control elements in the form of ListBox 73,75,77 for selecting the month and three control elements in the form of ListBox 74,76,78 for selecting the day that the user wants on exchange. Obviously, the number of control elements in the second portion is variable and depends on the configuration of the system. In this way, the user can offer his/her assigned day of vacation and select more than one day that the user wants on exchange.

The interface 70 also comprises a control element 79 in the form of a button.

When the user acts over said button 79 by means of the mouse a control signal is generated and the selected month in the control element 71 and the selected day in the control element 72 (the assigned day of the user) are captured by the system. Further, the selected month in the at least control element 73 and the selected day in the at least control element 74 are also captured (steps (B) and (C) of the method according to the invention).

In summary, the user selects the day he/she wants to offer and he also selects (at least one option) what he wants to get on exchange. The user then submits (acting over the button 79) the form and the system looks for results that match the query, for instance, in direct exchanges or 3-sides matches.

Fig. 8 shows a graphical user interface 80 for introducing a bid for exchanging an assigned work shift that can be used in steps (B) and (C) of the method.

The interface 80 comprises two parts: the first portion corresponds to the work shift that the user offers (the work shift assigned to the user) and the second portion corresponds to at least ona work shift that user wants on exchange. In the first part, the interface 80 comprises a first control element 81 in the form of a ListBox for selecting the month of his/her assigned work shift, a second control element 82 in the form of a ListBox for selecting the day of his/her assigned work shift, and a third control element 83 in the form of a ListBox for selecting the work shift that the user offers. When the user acts over the first control element 81 by means of the mouse, a control signal is generated to display all month of the year to the user, one of which is selected by means of the mouse for generating a control signal for determining the month selected by the user. When the user acts over the second control element 82 by means of the mouse, a control signal is generated to display all days of the previously selected month, one of which is selected by means of the mouse for generating a control signal for determining the day selected by the user. When the user acts over the third control element 83 by means of a mouse, a control signal is generated to display all work shifts regarding to the selected day of the month, one of which is selected by means of the mouse, for generating a control signal for determining the work shift selected by the user. In this way the work shift offered by the user is created.

On the other hand, the second portion of the interface 80 comprises at least a first control element 84 in the form of a ListBox for selecting the month what the user wants on exchange, at least a second control element 85 in the form of a ListBox for selecting the day what the user wants on exchange, and at least a third control element 86 in the form of a ListBox for selecting the work shift that the user wants on exchange. When the user acts over the first control element 84 by means of the mouse, a control signal is generated to display all month of the year to the user, one of which is selected by means of the mouse for generating a control signal for determining the month selected by the user. When the user acts over the second control element 85 by means of the mouse, a control signal is generated to display all days of the previously selected month, one of which is selected by means of the mouse for generating a control signal for determining the day selected by the user. When the user acts over the third control element 86 by means of the mouse, a control signal is generated to display all work shifts corresponding to the selected day of the month, one of which is selected by means of the mouse, for generating a control signal for determining the work shift selected by the user. In this way the work shift that user wants on exchange is created.

As can be also seen in Fig.8, the second portion comprises three control elements for selecting the month, three control elements for selecting the day, and three control elements for selecting the work shift that the user wants on exchange. Obviously, the number of control elements in the second portion is variable and depends on the configuration of the system. In this way, the user can offer his/her assigned work shift and select more than one work shift that the user wants on exchange.

The interface 80 also comprises a control element 87 in the form of a button.

When the user acts over said button 87 by means of the mouse a control signal is generated and the selected month in the control element 81 , the selected day in the control element 82 (the assigned day of the user) and the selected work shift in the control element 83 are captured by the system.

Further, the selected month in the at least control element 84, the selected day in the at least control element 85 and the selected work shift in the at least the control element 86 are also captured (steps (B) and (C) of the method according to the invention).

Basically, the user selects the day and the work shift he/she wants to offer and he/she also selects (at least one option) what he/she wants to get on exchange. Then the user submits (acting over the button 87) the form and the system looks for results that match the query, for instance, in direct exchanges or 3*sides matches. The work shifts shown as list/menu are the ones that had been registered for the specific job, so different jobs will have different interfaces depending on how they were registered.

In the case of an airline, the invention can be used to exchange work shifts between crew members. A crew member of an airline can work during a determined number of consecutive days in which they must spend the night in different cities and with variable starting and ending times.

Fig. 9 shows a graphical user interface 90 for introducing the number of days, the pairing number and the starting date of said pairing number. The pairing number serves to avoid having to fill the form again with the characteristics of the working period (starting and finishing hours and overnight stays, etc.), if it was previously filled out by any workmate. Said interface 90 comprises a first control element 91 in the form of a TextBox to input the pairing number (an identifier for a consecutive group of days of flights), a second control element 92 in the form of a ListBox for selecting the starting time of the pairing day, and a control element 93 in the form of a ListBox for selecting the number of consecutive days of said pairing number.

When the user acts over the first control element 91 by means of the mouse, a control signal is generated to capture the inserted text by the user, that is, the pairing number. The second and the third control elements 92,93 are automatically modified according to said pairing number. If the user acts over said control elements, the values can be changed.

The interface 90 also comprises a control element 94 in the form of a button. When the user acts over the button by means of the mouse, a control signal is generated to capturing the pairing number, the date and the number of consecutive days. Next, the captured data are sent to the system and the following two options are possible:

- The identifier (pairing number) and its characteristics, if the identifier has been previously registered by other worker, and the option to select if the data are OK. In the case of negative response, a new interface is shown to insert the right characteristics with a new name of the identifier.

- A graphical user interface (see Fig.10), for the number of days previously indicated, for selecting at least the starting and ending times and the places in which the crew must spend the night.

The interface 90 also comprises a control element 94 in the form of button.

When the user acts over said button by means of the mouse, a control signal is generated to capturing the pairing number, the date and the number of consecutive days by the system. Depending on the captured data a different new interface is displayed.

In summary, in this interface 90 the user selects the pairing number (an identifier for the series of flights), the starting date and the number of consecutive days of work. Depending on the number of consecutive days of work selected, a different interface will be shown. In the Fig.10 there is an example of a three day interface.

Fig.10 illustrates the graphical user interface 100 cited above. Said interface comprises as many portions as the number of consecutive days assigned to the pairing number. For example, if the number of consecutive days is three, the interface comprises three portions, one for each day. Each portion 101,102,103 comprises a first control element 104 in the form of a ListBox for selecting the hour of the check in time, a second control element 105 in the form of a ListBox for selecting the minutes of check in time, a third control element 106 in the form of a TextBox for inserting the final destination, a fourth control element 107 in the form of a XistBox for selecting the hour of check out time, and a fifth control element 108 for selecting the minutes of the check out time.

When the user acts over the first control element 104, a control signal is generated to display the different hours that the user can select (0 to 23), one of which is selected by means of the mouse for generating a new control signal for determining the hour selected. When the user acts over the control element 105, a control signal is generated to display the different minutes that the user can select (0 to 59), one of which is selected by means of the mouse generating a new control signal for determining the minute selected. When the user acts over the control element 106, a control signal is generated to capture the final destination inserted by the user (e.g. with a keyboard). When the user acts over the control element 107, a control signal is generated to display the different hours that the user can select (0 to 23), one of which is selected by means of the mouse for generating a new control signal for determining the hour selected. When the user acts over the control element 108, a control signal is generated to display the different minutes that the user can select (0 to 59), one of which is selected by means of the mouse for generating a new control signal for determining the minute selected.

The interface 100 also comprises a control element 109 in the form of a button. When the user acts over the button all data introduced in the interface is captured by the system.

Said interface 100 is the one returned by the system for a three day pairing flight. The user selects for each day, the check-in and check-out times and the places where the flight ends. Usually, the last day destination will coincide with the crew member home base. The interface only corresponds to what the user offers.

.«

Fig.11 illustrates a graphic user interface 110 for selecting what the user wants to get in return. Obviously, said interface is used when the company is an airline.

The interface 110 comprises a first group of control elements 111,112,113 in the form of ListBox for selecting alternative pairing starting days, a second group of control elements 114,115,116 in the form of TextBox for inserting alternative final destinations, a third group of control elements 117,118 in the form of option buttons for selecting if the check-in time is after or before a selected time, and a four group of control elements 119,120 in the form of ListBox for selecting the time of reference of the check-in time.

When the user acts over the control element 111 of the first group a control signal is generated to display all possible days of a month, one of which is selected, for generating a control signal to determine the selected day. The operation of the control elements 112 and 113 is the same.

When the user acts over the control element 114 of the second group of elements a control signal is generated to capture the text inserted by the user. The operation of the control elements 115 and 116 is the same.

When the user acts over the control elements of the third group, only one element can be selected, for generating a control signal to determine if the check-in time is after or before the time of reference.

When the user acts over the control element 119 of the fourth group of elements, a control signal is generated to display the different hours of the check-in time (0-23), one of which is selected for generating a new control signal to determine the hour of the check-in time. When the user acts over the control element 120 of the fourth group of elements, a control signal is generated to display .the different minutes of the check-in time (0-59), one, of which is selected for generating a new control signal to determine the minute of the check-in time.

The interface 110 also comprises a control element 121 in the form of a button. When the user acts over the button by means of the mouse, all data of the interface are captured by the system.

In this interface, the user can choose among three different starting dates (using OR) and the user can also indicate up to three different places he/she would like to stay at (also using OR) and whether he/she wants to check-in, before or after a specific time. The user must select at least one pairing starting date; the rest of the option may not be selected. Said interface 110 is send along with the previous one 100 to conform a bid. Fig.12 shows a graphic user interface 130 of user bids for exchanging a period of vacations and more concretely for exchanging an assigned fortnight. The user selects de fortnight he/she wants to offer (step B) and also selects (at least one option) what he/she wants to get on exchange (step C). The user then submits the form and the system looks for results (step D) that match the query in direct exchanges or 3-side matches.

The interface 130 comprises two portions: a first portion in which the offered fortnight is selected, and a second portion in which at least one desired fortnight is selected. The first portion comprises a first control element 131 in the form of a ListBox for selecting the month of the fortnight, a second control element 132 in the form of a ListBox for selecting the fortnight to exchange, and a third control element 133 in the form of a ListBox for selecting the year of the fortnight.

When the user acts over the first control element 131 a control signal to display all month of a year is generated. The user selects one of months by means of the mouse and said selection generates a control signal for determining the selected month. When the user acts over the second control element 132 a control signal to display all fortnights of the selected month is generated. The user selects one of said fortnights by means of the mouse and said selection generates a control signal for determining the selected fortnight. When the user acts over the third control element 133 a control signal to display a lot of years is generated. The user selects one of said years by means of the mouse and said selection generates a control signal for determining the selected year.

The second portion comprises at least one first control element 134 in the form of a ListBox for selecting the month of the desired fortnight and at least one second control element 135 in the form of a ListBox for selecting the fortnight desired by the user. In the interface of Fig.12 the user can select up to three different options of desired fortnights.

When the user acts on the first control element 134 a control signal to display all month of a year is generated, one of which is selected. Said selection generates a new control signal to determine the selected month. When the user acts on the second control element 135 a control signal to display the fortnight of the selected month is generated, one of which is selected. Said selection also generates a new control signal to determine the selected fortnight.

The interface 130 also comprises a control element 136 in the form of a button. When the user acts on the button a control signal to capture all data of the interface by the system is generated.

Fig.13 shows a graphic user interface 140 of user bids for exchanging a period of vacations and more concretely for exchanging an assigned week. The user selects the week he/she wants to offer (step B), and also selects (at least one option) what he/she wants to get on exchange (step C). Then the user submits the form and the system looks for results (step D) that match the query in direct exchanges or 3-side matches.

The interface 140 comprises two portions: a first portion in which the offered week is selected, and a second portion in which at least one desired week is selected. The first portion comprises a first control element 141 in the form of a ListBox for selecting the week number to exchange and a second control element 142 in the form of a ListBox for selecting the year.

When the user acts over the first control element 141 a control signal to display all weeks of a year is generated. The user selects one of the weeks by means of the mouse and said selection generates a control signal for determining the selected week. When the user acts on the second control element 142 a control signal to display a lot of years is generated. The user selects one of said years by means of the mouse and said selection generates a control signal for determining the selected year.

The second portion comprises at least one control element 143 in the form of a ListBox for selecting the week desired by the user. In the interface of Fig.13 the user can select up to three different options of desired weeks.

When the user acts on the control element 143 a control signal to display all weeks of a year is generated, one of which is selected. Said selection generates a new control signal to determine the selected week.

The interface 140 also comprises a control element 144 in the form of a button. When the user acts on the button a control signal to capture all data of the interface is generated.

As can be seen in Fig.14, the computer program for executing the method, described above comprises an lnit Module IM for starting the computer program of the invention; a Register Module RM connected to the lnit Module for capturing the inputs of a worker relating to personal data and at least one selecting parameter for assigning the worker to an appropriate group of workers (same company/same job); an Exchange Module EM also connected to the lnit Module IM in which the worker can input the bids for exchanging the assigned work shifts and/or periods of vacation; a Database Module DM used by the cited modules IM, RM, EM in which all the information (personal data, etc.) is stored; and a Communication Module CM that is used either to send or receive data from the workers, this module being able to generate emails and mobile phone messages and to get data from these messages and send said data to the modules that use it.

After accessing the program (for example from the Internet), the user is allowed to see the contents and simple instructions for use thereof from a start page or interface. This forms the lnit Module cited above.

In order to be able to make changes of shifts, working days or vacations or simply to consult the bids that workers have placed, it is necessary to be a "registered user". For this purpose, personal and company data as well as data about job or function performed therein must be provided voluntarily, besides accepting the stipulated legal terms of use. The program has the Register Module RM to carry out new user registration.

In addition to user name and passport (that uniquely identifies her/him in the system), her/his electronic mail address (email) and her/his mobile phone number are essential. From the lnit Module IM one can access the different options in the program, once the user has been identified correctly before the system.

Basically, the options offered by the computer program according to the invention can be:

- Changing shifts, guards or working days.

- Changing periods of vacations.

- Consulting the bids for changes of shifts, guards or days placed by workmates.

- Consulting the periods of vacations bid by workmates. - Consulting or deleting our own bids for changes.

- Consulting the data of our user registration in the system.

For this purpose, the program is divided into the several modules cited above.

Mainly, the computer program of Fig.14 can work in a multi-user client/server environment such as for example the Internet network.

Once registered (step H) with their contact and work data, users are enabled to place (steps A and B) their bids for changes of appointments, days, shifts or vacations, through a simple form, in which they further state what they want to receive in return (another appointment, shift, day or period of vacation, of similar duration). A user can ask for more than one option in return, consequently increasing their possibilities.

The program will search in its database (see Fig.16), among, for example, the bids placed only by workers in the same company and who are carrying out the same work or the bids placed by the patients of the same doctor, those fulfilling our requests and vice versa. These are the "direct changes."

It is important to highlight that, in the case of bids regarding medical appointments, it is possible to coordinate the schedule of the doctor with the computer program of the invention. .»

Furthermore, it will also look for those changes resulting from applying the "three way" module to the bids placed by users in the same labour group and company (or doctor, etc.). The "three way" module works as follows:

User A wants something bid by user B, user B wants something bid by user C, user C wants something bid by user A.

These are the "three way changes".

In this way, and since the same user may be ready to receive different periods for her/his bid, the possibilities of change multiply. These changes, when the number of workers is very high, can not be calculated with the traditional methods, as the difficulty of carrying out a three way change study for each of the options (user A) and further involving each of the options pointed out by users B and C, require, on one hand, to have all the information on bids from workmates, which often is not concentrated on only one place and, on the other hand, carrying out the different feasibility studies for each case.

The positive results of the search are shown and the user can select, among the direct or three band changes, those which are more interesting for her/him. A message is sent to users who have placed these selected bids.

User contact data is stored by the program in its database, and it automatically sends an email message and another similar to the mobile phone, with bid and contact data of the users involved in the change, so that they reach an agreement.

Until that moment user contact data have been kept hidden and they will only be seen by the users involved in the proposal of change, such that privacy is ensured.

If there are no positive results of change in that moment, the user can leave his/her bid recorded, if desired, waiting for some bids placed from another user, which is complementary to him/her. A user may further simply search the bids for changes of shifts, days or vacations placed by workers, to see if there is any that could be of interest.

As can be seen in Fig.15, the lnit Module IM comprises two different parts: those of public access and those of access restricted to "registered users".

The "public access" part consists of at least the following: - A program presentation.

- A form for system access identification to "registered users". - A link to the New User Registration Module RM.

- A link to the restricted part of the lnit Module.

The "restricted access" part consists of at least the following: - An access link to the Changing of shifts, guards and working days module.

- An access link to the Changing of vacation period module.

- A link where the registration data may be consulted.

- An access to the lnit Module public part.

For this reason the computer program of the invention comprises various modules. In summary, the lnit Module IM starts the computer program and generates the public area and the private area. The public area comprises the presentation of the program with an explanation of the program capabilities and an explanation of how to operate it; the user/ password form for inputting the identification of the worker and run the program as a registered user; and the new user register module link that starts the Register Module RM for fill-in the personal data of the worker and to become a registered user.

For the computer program works properly users need to be registered (see Fig.2 - step H) previously in the system. For this purpose, several options are considered:

b.1) A representative of the company, if it is not already registered in the system, contacts personally or by telephone those in charge of managing this program and provides the necessary data for uniquely identifying it in the system, such as for example the name of the company, country, state and city where it is located as well as, filter of users, a series of questions and answers that only the company workers may know, such as for example an extension telephone number, slang used by workers, a piece of text from a company manual, etc.

Some of these questions may be used as a filter in the registration of the new users who are identified as employees of that company, so that if they do not answer correctly several of those questions, they will not be able to proceed with the registration process.

b.2) The second option is the "On Line" registration in which the first user who registers a new company in the system sets out the "filter- questions" and indicates the company data that will identify it uniquely.

From there, registration of new users from an already registered company will be made "On Line". For this purpose, the user is requested to voluntarily fill a form with some personal data and data about the company where she/he is working.

b.3) The program is implanted in the company intranet environment. "Filter-questions" are not necessary as the own company takes care of managing the user identity providing them with suitable passwords and usernames.

"Filter-questions" are neither essential, possibly nor the most reliable option, but they are an inexpensive, simple and highly effective method for filtering undesired users in the new user registration process.

Among the necessary data there are:

- User name. - Password.

- Electronic mail address (Email). - Mobile phone number.

- Country, state, city and name of the company where the user is working. (For uniquely identifying that company in the system).

- Job, employment or function performed by the user in the company. - Characteristic timetables of that job (selected from a menu of possibilities).

- Any other considered as convenient.

The outline of the new user algorithm registration (see Fig.2) is self- explanatory. The new user begins to fill a registration form with the above mentioned necessary data, plus those considered as convenient for business, administration purposes, etc.

In the subsequent block, names of similar companies in the same geographic location are sought and they are shown if found, in the event that the company does not appear as registered, to check that a new one is not being

•.« created by mistake in the way in which the name of the company has been stored (adding for example: Inc., ltd., s.a., s.L, etc.).

When a new job, function or employment is recorded, the applicable timetables or shifts must be selected from a menu of possibilities (see Fig.6), for example, morning, afternoon, morning or afternoon, morning afternoon or evening, first-second-third, a-b-c-d..., with guards or not, etc.

If the job has been already recorded previously by another user, timetables or shifts already applied will be shown. In case of discrepancy with those shown, a new job can be created, with another name and timetables, or the system administration may be contacted for consulting doubts.

After answering the filter questions correctly, the registration data will be shown to check that they are correct as well as a legal contract, which must be accepted voluntarily, for being allowed to proceed with the registration.

It is also convenient to set a maximum number of attempts for correctly answering the "filter-question".

If everything has gone right, data are recorded in the system database, a unique identifier is assigned to that user (user ID) and two different random "activation codes" are automatically sent which may be as complex as appropriate, one to the electronic mail address (email) and another to the mobile phone.

A form will be correctly filled with these codes to that effect (see Fig.3), together with her/his user name and password, to activate her/his account and being allowed to share the program benefits as a registered user. Setting a maximum number of account activation attempts is also convenient.

The Exchange Module EM is of restricted use. Only registered users are allowed to access. Access may be gained from the private part of the lnit Module IM once they are correctly validated before the system, by means of their user name and password or whatever has been established as necessary for correct identification.

In this Module, requests for changes of shifts, guards or working days, consulting bids placed by workmates or checking or deleting bids placed so far may be carried out. It is accessed through a user interface, with all the available options, or in a more restricted way by using a mobile phone.

It is possible to send through the mobile phone (by using for this purpose the services of a communications company providing this kind of services, and the functions of the Sending-receiving messages module), a request for a change of shift, guard or working day. For this purpose, a message will be sent to the appropriate phone number, showing the date of the day, shift or guard desired to be changed and the date of those desired to be received in return.

A possible format of this message is shown further on although it may vary depending on the "Internet Gateway", the type of message that is desired to be sent or the communications company carrying out the data transport, etc.

The user interface has at least three different parts, one for changes (Change a Shift, Day or Call), another for checking available bids (Check All the Bids) and another for checking or deleting the bids (My Bids Admin. Panel).

From the "Change Option" the user can access the form for requesting change of shifts, guards and working days. This form (see Fig.7 and Fig.8), will show, at least, a box for the date of the day that we bid and the appropriate boxes for the dates ofi the days desired to be received in return. If the form is^for a shift work, applicable shifts will be further shown, for example on a drop down menu (the shifts shown are those recorded for that work in that company).

For making a change, what the user bid and what the user desires to receive in return must be selected in the "User Bids Input Interface" form (Fig.7 and Fig.8). The user can select more than one option regarding what the user want to receive in return, so his/her possibilities of success are increased, although a large number of "in return" options may slow down the "three search of results in the system.

For changing a shift for another one, the month, day and shift carried out must be selected and, on the other hand, at least, one day and month with its corresponding shift which the user would be ready to accept in return. If shift does not matter any may be select as an option. The system assigns a unique identifier to this request of change that is shown to the user.

For changing a guard for another one, the month and day when guard is carried out must be selected and, on the other hand, at least, one day and month which the user would be ready to accept in return. The system assigns a unique identifier to this request of change that is shown to the user.

For changing a working day for another one, the month and day the user desires to change must be selected and, on the other hand, at least, one day and month which the user would be ready to accept in return. The system assigns a unique identifier to this request of change that is shown to the user.

These forms, or the data in an appropriate format through the mobile phone, are sent to the server together with the characteristics uniquely identifying that user in the system (user ID). _*..

The program searches in the database the "direct changes" and "three way" changes, only among the employees in the same company and carrying out the same function and who are, by their characteristics, candidates to the change. A "candidate to the change" user is anyone carrying out the same function, in the same company, in the same geographic location and is different from the user placing the bid.

The program shows the results, if any, together with a check box by its side, so that we can select those of interest. The "direct changes" results will be shown with the date and shift (as appropriate) which the user can receive in return. The "three way" results will be shown with three boxes labelled "user- A (or the name of the user who places this bid), user- B and user-C" and clicking the mouse on them, the days, shifts or guards whir are bid and those requested in return will be displayed on a new window, so that the user can check that the search result is right.

In the results of the search, personal data which may identify the users easily will not be displayed.

Once selected the more interesting results, the program will send, automatically and using for this purpose the functions of the Sending- Receiving Calls Module and the services of a communications company, an electronic mail message (email) and a similar message to the mobile phone of the users involved in the change, with the necessary contact and bid identification data, so that the users involved may reach an agreement on how formalizing such a change.

It may happen that there is no result at that time for the request of change, and the program therefore gives the user the option of leaving her/his bid recorded or, if desired, deleting it and setting it out with different requirements of change or even deleting it definitively.

It is not possible to bid the same period twice by the same user. The program will alert the user that she/he is biding that period for the second time. The bid can be deleted and set it out in different terms if desired as many times as she/he wants, although it is advisable to first check the available bids in the option "Check Bids" and adapt the request to what is being bid. It is advisable that changes are carried out within the same month or validity period of time, for which the workers receive their work schedules.

A possibly special case, and to which this program is very effective, it that of airline crews, since they usually work during a certain number of consecutive days in which they also stay the night in different cities and with variable starting and finishing hours (see Fig.9). It is sent to the system and it replies with one of the two following options:

1. The identifier and its characteristics, if the identifier had already been previously recorded by another workmate, and the option of agreeing or not with what is being shown. If this is not the case, the user will access a new form where he/she will state the right characteristics, but with a different identifier name.

2. The form (GUI), for the previously stated number of days, in which at least the starting and finishing hours of the activity and overnight stays are selected (see Fig.10).

In the same reply answer form, what the user wish to receive in return may be also included, such as for example (see Fig.11):

- Different starting dates of the service period (day1, day2, day3...). At least one starting day must be selected. - Different places for overnight stays (may be left blank if it does not matter) (Iay1, Iay2, Iay3...).

- Starting hour of the first service day (for stating J3EF0RE or AFTER and it may be also left blank) (timel).

For not overloading the system the search may be conduct as follows:

day1 [(or day! or day3) and (Iay1 or lay! or Iay3) and (timel)]

according to BNF (Backus-Naur Form) notation in which: [...]- Option Meta-symbol.

(...)- Grouping Meta-symbol.

In a similar way to how it is carried out for other works, the program searches in its database the bids fulfilling the user requirements, at the same time the bid does theirs, and it shows the results, if any, together with a check box by its side. "Direct changes" results may be displayed in an abbreviated way, indicating, for example, the date and hour of starting or presentation of the first working day and the overnight stay places, and by clicking on the result, displaying the identifier with all his/her information (it is advisable in a different window).

For "three band changes" results, as the screen is possibly too small, it is more advisable to display the different results in lines showing, as above, "User-A, User-B, User-C" and again, by clicking on each one, seeing the complete characteristics of the identifiers to check if the result is right.

It is important to highlight that to carry out three band searches when many in return options have been indicated (for example different starting days at the same time that different overnight stay places, etc.), it may result in server slow down, due to the large number of consultations to be carried out in the database, so that it may be convenient to limit the options if three band changes are desired to be shared.

From the checking bids option the user can access a form from which "all" the bids of the day, shifts or guards carried out by workmates for a certain period may be checked. The user can also check the bids placed limiting the search for the days selected in the form. This option is useful if the number of bids stored for a certain period is very large.

It may be interesting to show, just for curiosity, the bids placed by other workers of the same company who do not belong to our same community, that is, they are not "candidates to the change". The reason thereof is motivating the use of the computer program according to the invention among the workers who are users of the program, as there may be communities making more use of this program than others do. The bid search results will be displayed, for a certain period of time, showing, on one hand, the dates and shifts (as appropriate) of what is being bid and the dates and shifts of what is being requested in return, and using different lines for each recorded bid. Bids placed by the own user will be also included as a result of these searches. It is advisable to further show, as a title, the community to which search results belong and providing links to the other sections of this program.

In the Bids Administration Option the user can "check" or "delete" the bids that he/she has placed and which are stored in the system database. For this purpose, if the user chooses to "check" the bids, all of them will be displayed, in separate lines, showing, for each one of them, what the user bid and what request in return. Next to each of these bids, a check button will further appear so that those selected bids can be eliminated.

Another possibility is to enter,«in a form to that effect, the bid number that the system showed him/her when requesting the change and selecting the deleting option. The program has to check, on one hand, that the bid exists and, on the other hand, that it corresponds to the user requesting its deletion. If everything is met, it will be removed from the system and if not, appropriate error messages will be displayed.

It is advisable that the format in which the bids placed are shown (separate lines for each bid, what is requested, what is bid, colours used, etc.) is similar to the formats used to show the results from other searches.

To modify a previously placed bid and which is stored in the database, it will be necessary to delete it and set it out again with different requirements.

In a Vacation Change Module (it can be a sub-module of the Exchange Module) the bids for vacation periods are placed. Operation is similar to that of a change of shift or working day. The main difference is that now what are changed are groups of consecutive days for another group of days of the same duration. Vacations are usually enjoyed in weekly, biweekly periods, and less often, in monthly periods.

Therefore, the changes of vacation request form (GUI) (see Fig.12 and Fig.13), will allow selecting, on the one hand, the week, fortnight, or month that is desired to change, and, on the other hand, the week(s), fortnight(s) or month(s) desired to receive in return. "At least" one period to change must be selected. For each change of vacation request a unique bid identifier is assigned.

To carry out weekly changes, the week number within a year has to be indicated (numbers from 1 to 52). It is convenient to display a calendar performing that calculation.

To carry out biweekly changes, it should be indicated whether the user bids the first one or the second one of a certain month and if the user wants the first one, the second one (or any if it does not matter) of another month.

The result search module is the same as for the change of shifts or days, simply that the type of data that is passed as a parameter is different: they are now vacation periods.

Direct results and "three band" results are shown separately and all of them having a checkbox by their side, so that the user can indicate the more interesting bids for him/her and that the program sends the messages, with the necessary contact data, to reach an agreement in the best way for making the change. For direct results it is recommended to show the whole bid, indicating what is requested and what is bid, to be able to check if the result is right. For "three band" results, it is better to show the results indicating User A (or the user name performing the search), User B and User C, and again clicking on them to show, in a new window, what they request and what they bid.

This Module also includes an Administration panel for user bids and another where to consult the vacation periods bid by workmates.

In the vacation bids administration part, if the user choose to "check" the bids, all of them will be shown, in separate lines, indicating, for each one of them, what the user bid and what the user request in return. A checkbox will further appear with each of these bids so that those selected vacation bids may be deleted. Another possibility is to enter, in a form to that effect, the number of the vacation bid that the system showed him/her when requesting the change and choosing the deleting option.

The program has to check, on the one hand, that the bid exists and, on the other hand, that it corresponds to the user requesting its deletion. If everything is met, it will be removed from the system and if not, appropriate error messages will be displayed. It is advisable that the format in which the bids placed are shown (separate lines for each bid, what is requested, what is bid, colours used, etc.) is similar to the formats used to show the results from other searches. To modify a previously placed bid and which is stored in the database, it will be necessary to delete it and set it out again with different requirements.

In a similar way to what it happened in the change of days or shifts, in Checking Bids the user accesses a form from which he/she can check "all" of the vacation bids placed by the workmates. It may be interesting to show, just for curiosity, the bids placed by other workers of the same company who do not belong to the same community, that is, they are not "candidates to the change". The reason thereof is motivating the use of the computer among the workers who are users of the program, as there may be communities making more use of this program than others do.

The results of the search of vacation bids will be displayed showing, on the one hand, the weeks, fortnights or months which are bid and the weeks, fortnights or months requested in return, and using different lines for each recorded bid. The bids for vacations placed by the own user as a result of this search will also be included. It is advisable to further show, as a title, the community to which the search results belong and to provide links to the other sections of this program. A direct link to the form of vacation change is advisable.

The communication module CM is used for sending messages to users or for receiving requests of changes of days, vacations, etc. and sending these data to the server so that they are processed. The messages sent are of two types, electronic mail messages (email) and messages to cellular phones (SMS, MMS, etc.).

For sending the electronic mail messages the appropriate functions of the different programming languages are used (SendMail(), Mail(), etc.), in which, at least, the text to be sent, the title of the message, the recipient and the sender should be indicated.

For sending messages to cellular phones, one must rely on services provided by a communications company that receives the data, for example, via Internet and sends them to the cellular phones through the appropriate network. These communications companies usually recommend using a "Script" program, in the different programming languages, for being able to make the data transfer from our server to theirs. These services are referred to as "Internet Gateway".

The data that the user has to provide from the computer program to that "Script" will be at least the phone number(s) of the recipient(s) (in international format), a text or message, and also the address in the Internet of the "Internet Gateway" server (where these data are sent to), and those data identifying the program as an authorized user to use these services, for example client name and password.

Basically the messages sent are the following: - Notice of change of day, guard or shift between 'two' users.

- Notice of change of day, guard or shift between 'three' users.

- Notice of change of vacation period between 'two' users.

- Notice of change of vacation period between 'three' users.

The data necessary to send these messages are:

1. Changes between 'two' users: (it is assumed two users A and B, and is the user A who sends the message).

- Email message: email address of recipient B, text indicating the type of change (vacations, day, guard, etc.) and further including the name and phone number of user A carrying out the request of change and the number of change bid identifier.

- Message to cellular phone: phone number of recipient B, text or content indicating the type of change (vacations, day, guard, etc.) and further including the name and phone number of user A carrying out the request of change and the number of change bid identifier.

2. Changes between 'three' users: (it is assumed to have user A, user B and user C and that is user A who sends the message). - Email message: email address of recipients users B and C, text indicating the type of change and further including: o For user B - phone number, name and identifier of the change bid of users A and C. o For user C - phone number, name and identifier of the change bid of users A and B.

- Message to cellular phone: phone number of recipients B and C, text or content indicating the type of change and further including: o For user B - phone number, name and identifier of the change bid of users A and C.

;» o For user C - phone number, name and identifier of the change bid of users A and B.

This Module is also capable of receiving requests of change sent by registered users through their cellular phones. Different strategies may be therefore used. On the one hand, there are communications companies offering a service called Two way SMS" in which the client, in this case the work shift ft vacation change software, is allowed to receive or send messages.

For receiving messages, the program manager will provide the users with a phone number to which SMS requests of change should be sent in a preset format. Afterward, the communications company will send him/her the data to the computer program via Internet.

A possible format for a shift change could be: nov12m 14m,15n

meaning that: the user changes nov (November), day 12, shift m (morning) for 14m (morning) or 15n (night).

From this message data are extracted, processed and recorded in the database. In the event that there are results to the change request, as they may be very large to be displayed on a phone screen, the program simply inform about this and that the user checks them later in the computer.

This strategy has the disadvantage that the communications companies bill the program manager for each message received, so that it may be very difficult to control the expense.

Another strategy may be the use of a short phone number (four numbers) where to send the messages. These numbers may be used solely (more expensive) or they may be shared with other companies. They use a key word added as a message header, for indicating the recipient thereof.

An example of this type of message may be:

SHIFT nov12n 14m, 15n

meaning that: the user change nov(November), day 12 shift n(night) for 14m(moming) or 15n(night) wherein the word SHIFT is the identifier.

This strategy has the advantage that the user who sends the message has to pay the sending, usually at a higher cost than sending a typical SMS message, and from this price, one part is destined to the program manager. The disadvantage is mainly the message cost.

Finally, it is also possible to use the advance of mobile phone technologies and which allows, in some cases, web pages to be directly accessed.

The database module DM comprises a database, their tables and registers, in which the personal and company data and the bids are stored. Different databases can be created depending on the data that must be stored. Its design basically depends on the number of users and on the number of variables that correspond to the type of interchanges to be performed.

The Fig.16 shows an example of the Database Module DM, which comprises a database, its tables and records, in which data about users, companies and change bids placed by users are stored.

There exist different ways of creating this database which will depend, to a large extent, on the data desired to be stored and benefits desired to be obtained.

Its design will also depend, to a large extent, on the number of users who are going to use it, although it is to be taken into account that, for example, for a company with 20,000 employees, which may seem a very large number of workers, since the users are divided into groups depending on the function carried out, there could be no more than 500 users who are candidates to a change and among them solely those who have placed bids, so searches of results, particularly three bands, are not as complicated as it could seem at first.

A database design is shown with the tables and some of the necessary fields (there may be many more) for carrying out registration of the users (User), the companies (Company), the different jobs (Job), the shifts corresponding to each work (Work_Shitfs) and shift change applications (Shift_Changes).

There is also a table in which the change requests asked will be stored (Changes_Track) showing the users involved. If only two users are involved, one of the fields will be NULL.

For the changes in vacation periods the outline is similar to the table "Shift_Changes" but instead of using fields with dates and shifts there will be fields with fortnights or weeks.

The new user records her/his personal data, data of the company and the name of the work that she/he is carrying out. The program will store in the table Work_Shifts the shifts selected in the registration form (see Fig.6), which better fits to her/his work characteristics.

This table is only one example. It may be as wide as required since the possibilities of shifts for the different works are very numerous_*

Work_Shifts table

Although the present invention has been described in detail for purpose of illustration, it is understood that such detail is solely for that purpose, and variations can be made therein by those skilled in the art without departing from the scope of the invention.

Thus, while the preferred embodiments of the method and the system have been described in reference to the environment in which they were developed, they are merely illustrative of the principles of the inventions. Other embodiments and configurations may be devised without departing from the scope of the appended claims.

Further, although the embodiments of the invention described with reference to the drawings comprise computer apparatus and processes performed in computer apparatus, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other form suitable for use in the implementation of the processes according to the invention. The carrier may be any entity or device capable of caπrying the program.

For example, the carrier may comprise a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disk. Further, the carrier may be a transmissible carrier such as an electrical or optical signal which may be conveyed via electrical or optical cable or by radio or other means.

When the program is embodied in a signal which may be conveyed directly by a cable or other device or means, the carrier may be constituted by such cable or other device or means.

Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant processes.

Claims

1. A method for exchanging a finite activity assigned to a first user with at least a second user from a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, the method comprising the steps of:

A) Identifying the first user;

B) Capturing the data relating to the assigned finite activity of the first user;

C) Capturing at least one finite activity desired by the first user;

D) Searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user, according to the data stored in the repository; E) Capturing the selected option of exchange among the at least one option;

F)ivBringing together the first user and the second user involved in the selected option;

G) Validating the exchange between the first user and the second user.

2. A method according to claim 1 , further comprising a step (H) of registering the first user in the repository.

3. A method according to claim 2, wherein step (H) of registering the first user in the repository comprises the sub-steps of:

H.1) Capturing the personal data of the first user; H.2) Capturing at least one selecting parameter for relating the first user to an adequate group of users;

H.3) Storing the personal data and the selecting parameter of the first user in the repository.

4. A method according to claim 3, further comprising the sub-steps before the sub-step (H.3) of:

H.4) Capturing an answer of the first user to at least one filtering question with reference to the assigned group of users; H.5) Verifying the answer of the first user.

5. A method according to any of claims 2 to 4, further comprising a step (I), between step (H) and step (A), of activating the first user.

6. A method according to any of claims 1 to 5, wherein step (D) comprises the sub-steps of:

D.1) Searching for the second user with an assigned finite activity equal to a desired finite activity of the first user;

D.2) Verifying if the second user is detected; if no results the control goes to sub-step (D.8);

D.3) Verifying if a desired finite activity of the second user is equal to an assigned finite activity of the first user; in the case of positive verification, passing the control to sub-step (D.7);

D.4) Searching for a third user with an assigned finite activity equal to a desired finite activity of the second user;

D.5) Verifying if the third user is detected; if no results the control returns to sub-step (D.1 );

D.6) Verifying if a desired finite activity of the third user is equal to an assigned finite activity of the first user; in the case of negative verification, passing the control to sub-step (D.4);

DJ) Storing the positive combination of three users as an option to exchange and returning the control to sub-step (D.4);

D.7a) Storing the positive combination of two users as an option to exchange and returning the control to sub-step (D.1 ); D.8) Verifying if at least one option is determined;

D.9) In the case of negative verification, waiting for a new entry; D.10) In the case of positive verification, appointing the options; D.11) Verifying if an option is selected.

7. A method according to any of claims 1 to 5, wherein step (D) comprises the sub-steps of:

D.1) Searching for the second user with a desired finite activity equal to an' assigned finite activity of the first user;

D.2) Verifying if the second user is detected; if no results the control goes to sub-step (D.8); D.3) Verifying if an assigned finite activity of the second user is equal to a desired finite activity of the first user; in the case of positive verification, passing the control to sub-step (D.7);

D.4) Searching for a third user with a desired finite activity equal to an assigned finite activity of the second user; D.5) Verifying if the third user is detected; if no results the control returns to sub-step (D.1);

D.6) Verifying if an assigned finite activity of the third user is equal to a desired finite activity of the first user; in the case of negative verification, passing the control to sub-step (D.4); D.7) Storing the positive combination of three users as an option to exchange and returning the control to sub-step (D.4);

D.7a) Storing the positive combination of two users as an option to exchange and returning the control to sub-step (D.1 );

D.8) Verifying if at least one option is determined; D.9) In the case of negative verification, waiting for a new entry;

D.10) In the case of positive verification, appointing the options;

D.11) Verifying if an option is selected.

8. A method according to any of claims 1 to 7, wherein step (F) comprises the sub-steps, if the selected option is a combination of the first user and the second user, of: F.1) Sending the personal data of the first user to the second user; F.2) Contacting the first user and the second user by means of the provided personal data.

5 9. A method according to any of claims 1 to 8, wherein step (F) comprises the sub-steps if the selected option is a combination of the first user, the second user and the third user of:

F.1) Sending the personal data of the first user and the third user to the second user;

10 F.2) Sending the personal data of the first user and the second user to the third user;

F.3) Contacting the first user, the second user and the third user by means of the provided personal data.

15 10. A system for exchanging a finite activity assigned to a first user with at least a second user comprising a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, and further comprising: 0 - Means for identifying the first user;

- Means for capturing the data relating to the assigned finite activity of the first user;

- Means for capturing at least one finite activity desired by the first user; 5 - Means for searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user, according to the data stored in the repository;

- Means for capturing the selected option among the at least one option; 0 - Means for bringing together the first user and the second user; and

- Means for validating the exchange between the first user and the second user.

11. A computer program comprising program instructions for causing a computer to perform the method of claims 1 to 9.

5

12. A computer program according to claim 11, embodied on a record medium.

13. A computer program according to claim 11 , stored in a computer 10 memory.

14. A computer program according to claim 11, embodied in a read-only memory.

15 15. A computer program according to claim 11, carried on an electrical carrier signal.

9s

16. A method for selecting an exchange option of a finite activity assigned to a first user with at least a second user, the method comprising the steps of: 0 S1 ) Capturing identification data of the first user;

52) Sending the captured identification data to a remote computer system for identifying the first user;

53) Capturing the data relating to the assigned finite activity of the first user and at least one finite activity desired by the first user; 5 S4) Sending the data captured in step (S3) to the remote computer system for determining at least one option of exchange; S5) Receiving the at least one option for exchanging the assigned finite activity of the first user with the second user according to the data sent in step (S4); 0 S6) Capturing the selected option of exchange among the received at least one option; S7) Validating the exchange between the first user and the second user.

17. A method according to claim 16, further comprising the steps before step (S1) of:

5 S8) Capturing registration data of the first user;

S9) Sending the captured registration data to the remote computer system for registering the first user.

18. A method according to claim 17, wherein step (S8) of capturing 10 registration data of the first user comprises the sub-steps of:

58.1) Capturing personal data of the first user;

58.2) Capturing at least one selecting parameter for relating the first user to an adequate group of users.

15 19. A method according to any of claims 17 or 18, wherein step (S8) comprises the sub-steps of:

58.3) Capturing an answer of the first user to at least one filtering question with reference to the assigned group of users;

58.4) Sending the answer to the remote computer system to verify it. 0

20. A method according to any of claims 17 to 19, further comprising the steps after step (S8) of:

510) Capturing activation data of the first user;

511) Sending the captured activation data to the remote computer 5 system to activate the first user.

21. A computer system for selecting an exchange option of a finite activity assigned to a first user with at least a second user comprising:

- Means for capturing identification data of the first user; 0 - Means for sending the captured identification data to a remote computer system for identifying the first user; - Means for capturing the data relating to the assigned finite activity of the first user and at least one finite activity desired by the first user;

- Means for sending the captured data to the remote computer system for determining at least one option of exchange; -Means for receiving the at least one option for exchanging the assigned finite activity of the first user with the second user according to the sent data;

- Means for capturing the selected option of exchange among the received at least one option; - Means for validating the exchange between the first user and the second user.

22. A method for exchanging a finite activity assigned to a first user with at least a second user from a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, the method comprising the steps of: ._*«

T1) Receiving identification data of the first user from a remote computer system; T2) Identifying the first user from the received data;

T3) Receiving data regarding to the assigned finite activity of the first user and at least one finite activity desired by the first user from the remote computer system;

T4) Searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user according to the data received in step (T3); T5) Sending the at least one option to the remote computer system; T6) Receiving the option selected among the at least one option from the remote computer system; 17) Bringing together the first user and the second user involved in the selected option; T8) Validating the exchange between the first user and the second user.

23. A method according to claim 22, further comprising the steps before step (Tϊ) of: 5 T9) Receiving registration data of the first user from the remote computer system;

T10) Registering the first user in the repository by means of the received registration data.

10 24. A method according to claim 23, wherein step (T9) of receiving registration data of the first user comprises the sub-steps of:

T9.1) Receiving personal data of the first user;

T9.2) Receiving at least one selecting parameter for relating the first user to an adequate group of users. 15

25. A method according to claim 24, wherein step (T9) comprises the sub- steps oi:

T9.3) Receiving an answer of the first user to at least one filtering question with reference to the assigned group of users from the remote 20 computer system;

T9.4) Verifying the answer of the first user.

26. A method according to any of claims 22 to 25, further comprising the steps after step (T9) of:

25 T11) Receiving activation data of the first user from the remote computer system;

T12) Activating the first user in the repository by means of the received activation data.

30 27. A computer system for exchanging a finite activity assigned to a first user with at least a second user comprising a repository of users which stores, for each user, data relating to an assigned finite activity and at least one desired finite activity associated with the assigned finite activity, the computer system also comprising:

- Means for receiving identification data of the first user from a remote computer system;

- Means for identifying the first user from the received data;

- Means for receiving data regarding to the assigned finite activity of the first user and at least one finite activity desired by the first user from the remote computer system; - Means for searching automatically in the repository at least one option for exchanging the assigned finite activity of the first user with the second user according to the received data;

- Means for sending the at least one option to the remote computer system; - Means for receiving the option selected among the at least one option from the remote computer system;

- Means for bringing together the first user and the second user involved in the selected option;

- Means for validating the exchange between the first user and the second user.

28, A computer program comprising program instructions for causing a computer to perform the method of claims 22 to 26.