Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/02—Marketing; Price estimation or determination; Fundraising
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data

Definitions

• the invention relates to a system and a method for inviting tenders for services, such as teaching, over an electronic network, such as an intranet or the Internet, said system comprising a relational database for recording and updating data concerning the public tender.
• EP-PS No. 0738446 discloses a system and a method for ordering services via a network connection between a user terminal and at least one central data processing unit with a database, where a user of the terminal can order services and receive information from the central data processing unit.
• This system is in particular adapted to deal with booking of hotel rooms and travel.
• EP-PS 0738446 suffers from major limitations. Via the existing system it is for instance not possible to ask questions concerning services not yet available. The existing system only allows such questions to be asked through a direct approach to a bidder of the system, and accordingly this system cannot be used for this purpose. In addition, the system according to the prior art does not render it possible for the bidders of the services to offer specific service requests presented by the customers either.
• a system is of particular interest to companies desiring to continue the training of the employees in a flexible and efficient manner.
• the object of the invention is therefore to provide a system for recording buyers, bidders, public tenders, service advertising and course evaluation; i.e. a market platform for advertising new courses and advertising for requested courses via an electronic network suffering from less limitations than hitherto known.
• the system according to the invention is characterised in that the relational database is divided into main areas with their respective function, such as a buyer file, a bidder file, a file handling the specifications of requirements applying to courses, a bid file, a file concerning submitted, but not yet used bids, instructors, course locations and news coverage, whereby items used by both the buyer, the bidder and the administration are logically related in such a manner that the data relating to the specifications of requirements and the bids can be added or changed anonymously by the buyers or the bidders, respectively, and subsequently be classified according to a predetermined set of stipulations by an at least partly automated system, which by means of the stipulations are able to select the best possible bid in view of the specifications of requirements presented.
• the resulting system for administration of services is much more flexible and efficient than hitherto known.
• the use of a relational database renders it possible to establish a logical relationship in the system between specific files used by both the buyer, the bidder and the administration with the result that changes of the data in question in a table are reflected in another table.
• the individual main areas of the database can furthermore be provided with their respective particularly adapted user interface in response to the use.
• relational database may according to the invention comprise a recording function for receiving data from the buyer file concerning buyer-id as well as buyer info.
• the individual buyers can be uniquely identified by the remaining users of the system.
• relational database may according to the invention comprise a public tender function handling the administration of the progress of said public tender from the submission of the first draft to the setting up of the specification of requirements used as the basis for the public tender.
• the resulting system renders it possible to electronically invite tenders in a anner meeting the conditions and specifications relating to public tenders while it is simultaneously possible to com- pletely benefit by an electronic market platform.
• relational database may according to the invention comprise a semi-automated bid evaluation function, which at the termination of the public tender period is able to select the best possible bid among a number of submitted bids on the basis of a plurality of predetermined, rated selecting criteria.
• the resulting system can in a fast and reliable manner eliminate uninteresting bids on the basis of the requirements presented by the customer.
• the relational database may according to the invention comprise an evaluation function for processing and subsequently evaluating the written feedbacks of the participants in a course.
• a system is obtained which in a standardized and unique manner can carry out a continuous control of the quality of the teaching, which is beneficial to both the course bidders and the customers.
• all the users of the system may according to the invention be recorded, and each user can be designated a security level ensuring that only course buyers have access to reading or changing the data relating to the buying of courses, and that only course bidders have access to reading or changing the data relevant to the establish- ment or bids of courses.
• a unique control of the bids and the buying of courses is ensured, and furthermore it is ensured that the conditions and specifications of the public tenders are observed by the administration.
• the invention relates also to a method for controlling and administering public tenders, especially via electronic networks, said method being characterised by the steps of stipulating a set of provisional requirements to the contents of said public tender, of storing said set of requirements as a first draft, and of allowing an exchange of questions and answers between the caller for and the buyer of said public tender during a first predetermined period, and by using the result of these questions and answers to continuously adjust the contents of said public tender during said first predetermined period, by storing the public tender bids from callers for a tender during a second predetermined period in such a manner that the individual bids are not accessible prior to the expiration of the second predetermined period, that the bids submitted are made publicly available after the expiration of the second predetermined period, and finally that the bid meeting most of the requirements stipulated in the contents of the public tender is selected among the submitted bids.
• a method for inviting callers for tenders via electronic networks is obtained, said method being far more flexible and efficient than hitherto known.
• the exchange of questions between the caller for a tender and the tender-awarded party can be carried out anonymously , but completely publicly by means of a publicly accessible network, such as an intranet or the Internet with the result that all the tender-awarded parties can follow the questions and answers as well as the changes which said exchange of questions and answers causes in the specifications of requirements of the caller for a tender.
• the selecting of the best bid may according to the invention be carried out by a general, comparable bid profile initially being set up for each submitted bid, whereafter the bids not meeting the invariable requirements to the bid stipulated by the buyer are eliminated, and by the individual items of the remaining bids subse- quently being rated in such a manner that each item of each bid is designated a rating factor between 0 and 1, said rating factors subsequently being multiplied with the cost price for each item in each bid, and finally by the resultantly adjusted cost prices of each bid being added up and then added to a basic amount for the bid in question.
• the individual bids are uniformly adjusted in such a manner that they are comparable.
• the unsuitable bids can also be eliminated.
• Such bids are for instance eliminated in the situations where specific subjects are not covered by the offered courses; where desired facilities are not available at the course location selected; or where a specific type of course, such as residential courses, are not offered.
• the rating factor of the individual items renders it possible to adjust the individual bids relative to the importance of the individual items.
• a specific bid does not include a specific item, and when this item is not specifically required by the caller for a tender, the bids without this item are favoured with respect to price at the expense of the bids including the item in question.
• Such a situation is taken into account by figuring a fixed estimated price for the item in question in the bids not including this item with the result that the completed indices of the individual bids are comparable.
• the individual tenderers may according to the invention be informed of the preferred bidder in the public tender in question, and furthermore a confirmation of the bid may according to the invention be sent to this preferred bidder.
• all the callers for the tender in question are informed of the result when the public tender has been terminated.
• all the callers for the tender may according to the invention be informed in writing of the result, viz. that no successful bidder has been found in the public tender.
• all the callers for the tender in question are informed of the fact that the stipulated requirements have not been met.
• the course of the completed public tender can be stored in order to be subjected to a subsequent analysis.
• the system is preferably structured as an interface-oriented database system, which
• the relational database can for instance be structured by means of one of the existing implements for establishing relational databases, such as SQL, Oracle ® or BDE. SQL and Oracle ® are development tools available for instance from Oracle Corporation. BDE (Borlard Database Engine) is available from Inprise Corp. , Scotts Valley, California.
• the software for executing the individual database functions and for controlling the access to the database can be structured in an object-oriented language suited for the purpose, such as Visual Basic ® , Delphi ® or JavaTM. Visual Basic is available from Microsoft Corp. , Redmond, Washington. Delphi is available from Inprise Corp., Scotts Valley, Cali- fornia. Java is available from Sun Microsystems Inc., Palo Alto, California.
• This public tender system involves four "parties"; course bidders, course buyers, participants in a course and the administration.
• a course bidder offers courses, sets up courses and submits tenders for requested services.
• a course buyer asks for courses, enrols participants in the courses and requests services from the course bidder. These services are typically covered by a specific course which the buyer wishes to hold.
• the participants in a course provide a feedback of the quality of the courses held in form of evaluation reports.
• the administration establishes the contact between the course bidders and the course buyers, coordinates the courses offered, the enrolments and the course locations, as well as takes care of the superior control of the courses of the public tenders.
• the administration controls and decides who has access to reading and changing, respectively, the data in the system.
• the system uses a relational database for recording and updating the data concerning the public tenders.
• This database is divided into a plurality of different main areas with their respective function.
• the most essential functions are: a buyer file; a bidder file; specifications of requirements presented to courses; a bid file; a file concerning submitted, but not used bids; a public tender agenda and a public tender log.
• the last two functions are used for observing terms for .public tenders and for recording the course of the public tender.
• Fig. 1 illustrates a chart of the data flows in a system according to the invention
• Figs. 2a, 2b and 2c illustrates the structure of the relational database
• Fig. 2d illustrates the data flows for the market platform and the public tender course
• Fig. 3 illustrates the data flow at level 0 in a system according to the invention
• Fig. 4a illustrates the part covering the handling of courses
• Fig. 4b illustrates the part covering the selecting of a bidder
• Fig. 4c illustrates the part covering the selecting of a teacher
• Fig. 4d illustrates the part covering the selecting of a location
• Fig. 4e illustrates the part dealing with the exchange of information
• Fig. 5a illustrates the part dealing with the administration of the number of participants in a course
• Fig. 5b illustrates the part dealing with the orders of courses from the customers
• Fig. 5c illustrates the part dealing with the administration of the participants in a course
• Fig. 5d illustrates the part dealing with the administration of course bidders
• Fig. 5e illustrates the part dealing with the teachers
• Fig. 6 illustrates the part dealing with the administration of courses.
• the system illustrated in Fig. 1 has been implemented by means of a relational database, and it comprises a number of interconnected objects, viz. a recording object 1, a public tender object 2, an evaluation object for bids 3, an evaluation object 4 and a market platform 5.
• the system comprises the two inter- faces, viz. buyers and course bidders, which are able to exchange data with the objects in specific ways which are explained in greater detail below.
• Two further interfaces, viz. participants in a course and analysis, are also part of the system.
• the system comprises a buyer file, a bidder file, a file handling the specifica- tion of requirements, a bid file, bids, a file handling the public tender agenda and a public tender log file.
• the recording object 1 receives the necessary data from the buyer file. These data are inter alia the buyer-id which is a unique identification number in the system for each buyer, and a buyer info which for instance shows the courses in which the buyer has previously shown an interest. New buyers submit data to the buyer file through the recording object 1, and already recorded buyers can update the data in the buyer file in a similar manner. When a public tender is started, the drafts are stored in the file containing the specifications of requirements through the recording object 1, and already stored drafts can also be downloaded from said file.
• the public tender object 2 is the central part of the system. This object handles the administration of the progress of the public tender from the submission of the first draft to the final selection of course bidder.
• the recording object 1 is used for starting a public tender.
• the stipulation of an actual specification of requirements is based on a draft, and this specification of requirements is used as the basis for the public tender.
• the buyer can answer questions presented by the bidders interested in submitting a bid on the public tender in question through the public tender object 2, and during the same period these buyers can have access to reading the answers submitted.
• the answers are submitted anonymously in order to allow both the buyer and the bidder to read the questions and the answers without revealing the identity of the inquirer to other bidders.
• the progress of the public tender is recorded continuously in the public tender log file, and the file housing the public tender agenda ensures that the terms relating to the questioning period and the public tender period are observed.
• the bids being submitted are stored in the bid file housing topical bids, and the reception of each bid is signed for through the public tender object 2.
• the bid evaluation object 3 is used at the end of the public tender period for selecting the best possible bid among the bids submitted.
• the bids submitted are stored in a bid file so as to be the subject of statistics.
• the buyer evaluates the individual bids on the basis of some selecting criteria , such as a forced study of specific items in the teaching, the price, the educational materials etc, and through the bid evaluation object 3 the buyer subsequently informs the preferred bidder and the remaining bidders participating in the public tender of the result as well as of the reasons form- ing the basis of said result.
• this result is also transmitted to the recording object 1 and the public tender object 2 so as to initiate a new public tender and the drafting of a changed specification of requirements.
• the evaluation object 4 is used by the buyers for evaluating the bidders after termina- tion of a public tender.
• the evaluation object 4 is used in connection with the feedback reports from the participants in a course.
• a standard evaluation form is handed over to each participant in the course, and after the form has been filled in each participant returns said form to the evaluation object 4.
• the analysis file handles the function in the system carrying out said analysis and the evaluating procedure which the evaluation forms are subjected to.
• the latter evaluation procedure can in principle be carried out by the course buyer, but it is usually handled by a specialized consultant company.
• the market platform object 5 allows the buyer to advertise for new public tenders and to carry out general service requests concerning courses not yet available or particular courses. Furthermore, the market platform object 5 allows the bidders to see pending public tenders or to offer new types of courses or new subject areas.
• the structure of the relational database via the market platform is illustrated in Figs. 2a and 2b. This structure comprises the following tables with the described contents:
• Adminlevel Information on employees having access to course data at various levels admlevelid: Code for indicating the identity username: Name of the user in question levelvalue: Access level in the system
• courses Information on courses courseid: Id-Number of the course; primary key
• Bidderid Id-Number of the bidder courseno: The inhouse course Number of the bidder coursename: The name of the course type: Type of course price: Price per participant instid: Teacher-id duration: Duration of the course totalseats: Number of seats in the course datecreation: Date of creation information: Information on the course etc intro: Introduction to the course target: Target group of the course experience: Expected knowledge of the participants aims: The aim of the course content: Brief description of the contents of the course url: (universal resource locator) web-site of the information
• coursesplace Information on course locations placeid: Id for course location; primary key bidderid: Id-Number of bidder placename: Name of course location street: street or road name number: House Number zipcode: Postcode url: (universal resource locator) web-site of the information instid: Teacher-id
• coursestable Information on course, time, Number of participants and location for the course coursetableid: Id-Number of the course courseid: Id-Number of the course date: Course date time: Period of time of the course signedupno: Number of participants having signed up placeid: Id for course location instid: Teacher-id
• Bidderid Bidder-id company: Company name street: Street/road name number: House Number zipcode: Postcode phone: Phone Number fax: fax Number email: e-mail address web: Site for the web page of the bidder url: (universal resource locator) web-site of the information datecreation: Date of creation cvr: The CVR Number of the bidder state: status of the bidder
• participant- company Information on companies buying courses participid: Participant-id usename: Name of user company: Name of the company street: Street/road name number: House Number zipcode: Postcode phone: Phone Number email: e-mail datecreation: Date of creation contactoame: Contact person in the company
• pai u i ⁇ aui- name Information on participants participid: Participant-id Number username: User name firstname: The first name lastname: The surname email: e-mail address company: Company name
• participant- table Information on courses, times, course buyers and course loca- tions _ participid: Participant-id Number courseid: Course-id Number coursedate: Date of course admid: Administrator-id coursetableid: Table-id
• Bidderid Bidder-id firstname: The first name lastname: The surname email: e-mail address state: Status of the user
• zipcodecity Information on postcode and name of city zipcode: Postcode city: Name of city
• lecturer Information on lecturer lecturerid: Lecturer-id firstname: The first name lastname: The surname company: The company street: Street/road name number: House Number zipcode: Postcode city: Name of city emailadress: e-mail address privatephone: Private phone Number workphone: Phone Number at work mobilphone: Mobile phone Number fax: fax Number title: Title of lecture duration: Duration cv: Data maintheme: Main theme othertheme: Other themes place: Location of lecture eastprice: Price per participant residing east of Storebaelt ("The Great Belt”) westprice: Price per participant residing west of Storebaelt ("The Great Belt”) picture: Picture of the lecturer
• lecturercontact Information on how to get in contact with the lecturer contactid: Contact-id Number fname 1 : First name of contact person lnamel: Surname of contact person phone 1: Phone Number of contact person email 1 : e-mail address of contact person info: Information on contact person lecturerid: Lecturer-id Number date: Date of creation state: status of the contact person
• course_desc Description of course. course_desc_id: Description-id
• Bidderid Bidder-id course_desc_values: Description values course_desc: Description course Me: Title of course course_aim: Aim of course course_success: Succeeded course_participants: Participants course_period: Period course_year: Year ' coursejplace: Location course_condition: Status course_duration: Duration course_participants_max: Maximum Number of participants course_q_end: Questions ended course_a_end: Answers ended course_tendersubmit_end: Change ended course_state: Status course tempid: Temporary id-Number
• the purpose of the tables relating to the public tender is to ensure an efficient performance of the individual steps of the public tender course.
• the latter has inter alia the effect that not all having access to the system can read or write in the various tables.
• Fig. 2d illustrates the superior model of the data flows in the entire system according to the invention, said model including a market platform surrounded by a broken line and a public tender part surrounded by a dotted line.
• Concerning the references see the explanation relating to Figs. 2a, 2b and 2c.
• Several tables are common to the two parts of the system. The relations are multiple in several cases, viz. that more items in a table are associated with several other items in another table, which has been indicated by the two tables in question being interconnected through a box with an inclined drawn line in the Figure.
• the dividing of the system into a public tender part and a market platform ensures that the public tender part is only accessible to certified users.
• a draft is initially sketched out.
• This draft stipulates the aim of the course, the expected knowledge of the participants and the teachers, the contents and schedule of the course.
• This draft can be stored so as to allow a resuming of the setting up of the final specifications of requirements at a later stage.
• a suitable number of requirements have been stipulated for the public tender, said public tender is sent out.
• the public tender enters the phase where an inquiry round is possible for a limited period of time, and during which the course bidders can present questions to the public tender in question. These questions are presented anonymously. Questions can be presented to the public tender until the term for the questioning period expires.
• the public tender is also subject to a time limit.
• Each interested course bidder can submit a bid concurrently with the inquiry round, and he or she can issue variations to this bid in response to the answers given to their questions.
• the public tender system provides the buyers and bidders with a set of functions or implements for controlling the public tenders being initiated. Some functions are common to both parties, but other functions are reserved for either the buyer or the bidder. The availability of some functions to the buyer and the bidder depends furthermore on the stage of the public tender progress. When the term has expired for an inquiry round, a bidder can for instance no longer issue variation to the bid material.
• a course buyer has the possibility of setting up a new public tender, of downloading a previously stored draft, a master or a previous public tender, of storing a draft as well as of sending out the completed public tender.
• the system renders it possible to enter data concerning the specifications of the desired course. These data can always be stored as a draft which can be resumed later on in order to draft the specification of requirements per se.
• the course buyer can participate the inquiry round associated with the public tender, and here answer questions from the course bidders.
• the course buyer must be able to change the specification of requirements or optionally to cancel completely the public tender already sent out.
• the course buyer cannot see the submitted bids before the term for submitting bids has expired.
• a conventional public tender the latter is ensured by all the bids been submitted in sealed envelopes which are not opened until the submitting term has expired.
• Such a procedure can be difficult in connection with digital public tenders because all the bids must be submitted in sealed envelopes in accordance with the stipulated provisions relating to the public tenders, and because all the callers for a public tender have a right to attend the opening of said sealed envelopes.
• the course buyer is indeed allowed to know the number of bids submitted in connection with the public tender in question.
• All the bids submitted must be considered submitted in sealed envelopes by the course buyer. After the opening of the sealed envelopes, all the bids must be published together with the total estimated costs as well as the name of the course bidders having submitted said bids.
• the system includes an independent function, and the only purpose of this function is to publish the bids to the course buyer at the same time as said bids are made publicly available to the course bidders.
• the course buyer After the opening of the sealed envelopes with the bids, the course buyer has access to all the data contained therein whereas the individual course bidders are only able to see the estimated costs as well as the names of the other bid-submitting bidders. Subse- quently, the individual bids are evaluated so as to find the most advantageous bid among the submitted bids.
• the opening and publishing of the submitted bids is followed by a predetermined period of time during which the course buyer can select the most advantageous bid or possibly reject all the submitted bids.
• a confirma- tion is sent to the bidder who signs for and returns the confirmation to the course buyer. After receipt of this confirmation, a rejection is sent to the remaining bidders.
• the bids can be evaluated in many ways. This evaluation can for instance be a mere comparison of prices where the lowest price is selected, or it can be an evaluation where the bid meeting most of the specifications of requirements presented to the requested services is selected. Usually, the price and services are rated.
• the evaluation of bids is carried out by means of the so-called "rating-model" .
• the bids When the bids are received by the customer, they have been arranged according to the prices found in the basic specifications.
• Each rating profile includes requirements, a rating and estimated prices for each of the items defined per customer.
• the requirements refer to the items which must be included in the bid.
• the rating means that the item appears from the calculated index with a specific adjustment essential to the size of the index. Thus a rating of 100% implies that the item in question in the bid is included in the indicated price, whereas a rating of 0% implies that the item has no effect on the index at all.
• Such a rating can be important for the comparison of bids based on different items, such as bids where the transport charges can be paid independent of the course organizer and are therefore not included in the index.
• the estimated price means an option to adjust the index in connection with provisos.
• the indicated value of the estimated price is used for calculating the index in such a manner that the individual bids are comparable although a specific item does not appear from one or more bids.
• the index per se is calculated as the price of the basic service plus the rated price of all additional options.
• the index provides a comparable indication of the relation between price and quality of the individual bids.
• the presentation of the rating profiles in the system results in an arranged order of the bids where the rating profile with the lowest index represents the bid presenting the best relation between price and quality.
• a typical public tender procedure is described below with reference to Fig. 1 as well as Figs. 3 to 6.
• the public tender and administration system is described in three levels of details with respect to function.
• the access to the individual functions is controlled individually for all the users of the system.
• the central relational database described above is here referred to as course base.
• Courses can be selected on the basis of various criteria, such as subject, bidder, teacher or course location.
• Fig. 3 illustrates part of a data flow chart for level 0 in the system.
• Courses: 1 indi- cates the courses accessible in the system at a specific time; bidder: 2 represents the bidders either including the course in their course catalogue or having the capacity to set up said course; teachers: 3 refers to the teachers able to hold the course in question; locations: 4 refers to the possible locations or course sites based on facili- ties and expected number of participants; info & adm. : 5 refers to the central administration of the system.
• the administration is able to receive data concerning bidders, courses, teachers, locations and participants, and based on these data the administration is able to generate lists of courses, lists of participants, lists of teachers and lists of locations.
• Fig. 4a illustrates the part of the system handling the courses. This part is found on level 1.
• Select course: 1.1 refers to the option of selecting a course; download data on the course: 1.2 locates data in the course base relating to the course in question; show/order courses: 1.3 is able to show the results and allow the user to order a course. All the courses are provided with a course-id-Number used for locating a specific course in the course database. The "raw" data from the course database are presented in an easily read form by 1.3, which furthermore can send out a confirmation of the order of the course in question.
• Fig. 4b illustrates the part of the system covering the selecting of a specific bidder. This part is found on level 1.
• Select bidder: 2.1 renders it possible to select a bidder;
• select course: 2.2 renders it possible to select a course among the courses offered by the bidder in question in his catalogue; download course data: 2.3 locates the data relating to the course in question in the course database;
• ordering courses: 2.4 renders it possible to order a course in the same manner as shown in Fig. 4a.
• Fig. 4c illustrates the part of the system covering the selecting of a specific instruc- tor. This part is found on level 1.
• Select course category: 3.1 renders it possible to select course category according to subject;
• select instructor: 3.2 renders it possible to select a specific instructor among the instructors capable of holding the course in question; download instructor data: 3.3 locates data concerning the instructor in question in the course database. All the instructors are assigned a unique instruc- tor-id-Number in the course database, said id-Number being used for locating a specific instructor in the course database. This id-Number is furthermore related to data concerning the qualifications or subject area of the instructor in question.
• Fig. 4d illustrates the part of the system dealing with the selection of a specific location. This part is found on level 1.
• Select destination category: 4.1 renders it possible to select a destination category; counties: 4.2 renders it possible to choose between various counties; cities; 4.3 renders it possible to choose between various cities; download location data: 4.4 renders it possible to locate data on a specific course location.
• Each location is assigned a unique location-id-Number in the course database, said location-id-Number being used for locating a specific location in the course database. This id-Number is furthermore related to data concerning the geographic siting of the location in question, the course facilities, the standard with respect to food and the transportational possibilities.
• Fig. 4e illustrates the part of the system dealing with the general exchange of data. This part is found on level 1.
• the course buyers are able to add or change data relating to participants in a course or to request courses; the bidders are able to insert data on the bid and the courses as well as to ask the buyers questions; the instructors are able to provide instructor data and ask for specific instructor skills; course locations are able to instructor data and ask for specific instructor skills; course locations are able to provide data on locations; and the news service is open to all users having access to the system.
• 5.1 renders it possible for course buyers to print out course lists; 5.2 renders it possible for course bidders to print out lists of courses, participants, locations and instructors; 5.3 renders it possible for instructors to enlist qualifications etc; and 5.3 renders it possible for course locations to enlist facilities etc.
• the individual user platforms exchange data with the course database in which all the data are stored.
• Fig. 5a illustrates the part of the system handling the administration of number of possible participants in an existing course. This part is found on level 2.
• Find course description: 1.2.1 and 2.3.1 find data on the description of the course in the course database on the basis of an assigned course-id-Number.
• Updated calculated number of participants: 1.2.2 and 2.3.2 calculate on the basis of the located course data the number of vacant seats in the course in question on the relevant date. Red, yellow, green: 1.2.3 and 2.3.3 update on the basis of the number of vacant seats the course data in response to a request.
• These course data also show whether seats are still vacant, whether the course is full up or whether the course is overbooked, as well as the number of participants enlisted on a waiting list, if any.
• Fig. 5b illustrates the part of the system dealing with the customer's order of courses from the course bidders. This part is found on level 2.
• Book course 1.3.1 books a specific course on the basis of course data received from 1.2.3 and 2.3.3 of Fig. 5a.
• Course ordering list 1.3.2 generates a course order list to the course buyer in question on the basis of the booking data resulting from 1.3.1.
• Fill in participants lists: 1.3.3 renders it possible for the buyer to fill in participants lists.
• Order courses: 1.3.4 is able to receive the completed order data and to create the final order. The latter is carried out by the relevant data in the course database being updated whereafter a confirmation is sent to the customer.
• the order list is generated by 1.3.2 and is also based on the data from the course database.
• 5c illustrates the part of the system handling the administration of the individual participants. This part is found on level 2.
• Login: 5.1.1 is a log-in checking the access to the system by comparing an entered password with the password stored in the course database and mating the user name in question.
• Participants info. : 5.1.2 renders it possible to show participants info, such as the address of the participant, to change these data, to show courses signed on by the participants etc. These functions are made accessible to each participant by means of the participant-id-Number allowing access in connection with the login.
• Fig. 5d illustrates the part of the system handling the administration of course bid- ders. This part is found on level 2.
• Login: 5.2.1 is a log-in checking the access in the same manner as 5.1.1 of Fig. 5c.
• Course: 5.2.2 renders it possible to select a specific course among the courses found in the course catalogue from the bidder in question. Here it is also possible for the bidder to show, set up and change courses, and it is possible to generate course lists and lists of participants.
• Cancel course: 5.2.3 renders it possible for the bidder to cancel a course. The updated data are exchanged with the course database.
• a cancellation can for instance be necessary in the situation where the number of enrolments in the course is not sufficiently high at the expiration of the enrolment term, or when the instructor cannot hold the course and no substitute instructor can be found.
• Change of bidder info.: 5.2.4 renders it possible change the bidder data. Such changes are for instance change of address or change of the type of courses which the bidder can offer.
• Participants: 5.2.5 renders it possible to enrol and cancel participants in a course or to change the data relating to each participant. It is furthermore possible to see the id of the person having inserted, enrolled or cancelled the participant in question.
• Lists 5.2.6 generates lists of courses, instructors, locations and participants on the basis of data from the course database.
• Fig. 5e illustrates the part of the system relating to the instructors.
• Login: 5.3.1 is a log-in ninning an access check in the same manner as described above.
• Show instructor: 5.3.2 renders it possible to generate course lists, lists of participants and to show data relating to the instructor in question.
• Change instructor-info: 5.3.3 renders it possible to change the data relating to each instructor. 5.3.2 locates the desired data in the course database. 5.3.3 stores the changed data in the course database.
• Fig. 6 illustrates the part of the system handling the administration of the individual courses. This part is found on level 3.
• Show course: 5.2.2.1 renders it possible to show the course in question; change course: 5.2.2.2 renders it possible to change an existing course; to setup a course: 5.2.2.3 renders it possible to set up a new course.
• 5.2.2.1 receives a course-id-Number and a bidder-id-Number and checks by means of the course database whether the course exists and whether the course-id and the bidder-id agree. Based on these data 5.2.2.1 can subsequently generate lists of cours- es and lists of participants according to desire.
• Each course can be changed in 5.2.2.2, which can receive data on the course, and the changes are stored in the course database.
• 5.2.2.2 can receive data on the course, and the changes are stored in the course database.
• a new course is to be set up, it is also possible to insert data relating to said new course in 5.2.2.3 storing the new data in the course database.
• Figs. 3 to 6 represent interfaces between the user interface of the system and the course database.
• the interfaces execute the functions associated with the individual types of users, but they administer the access level as well of said users to the individual data found in the course database.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• Accounting & Taxation (AREA)
• Development Economics (AREA)
• Finance (AREA)
• Strategic Management (AREA)
• General Physics & Mathematics (AREA)
• Entrepreneurship & Innovation (AREA)
• Marketing (AREA)
• General Business, Economics & Management (AREA)
• Economics (AREA)
• Game Theory and Decision Science (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• General Engineering & Computer Science (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=8159128

Family Applications (1)

Country Status (2)

Cited By (2)

• 2001
  • 2001-02-14 AU AU31539/01A patent/AU3153901A/en not_active Abandoned
  • 2001-02-14 WO PCT/DK2001/000099 patent/WO2001059631A2/fr active Application Filing

Also Published As

Similar Documents

Legal Events