"An e-learning gateway"
INTRODUCTION
Field of the Invention
The invention relates to computer-based learning ("e-learning"), in which content is downloaded by a content provider to a student computer for a learning course.
Prior Art Discussion
At present, users have a choice of multiple available learning management systems (LMSs) from different suppliers. The e-learning content for the LMSs are delivered via a variety of channels, some being loaded by CD or DVD into a local server, and others being downloaded from the Internet. The users and network supervisors must at present install courses, implement tracking procedures, load/catalogue the content to be used, handle updates and maintain servers.
For example a learning management system may support AICC HACP version 2.2 to level 2. This means that content that is AICC HACP version 2.2 level 2 compatible should be able to be plugged into this LMS and work first time. Content that is level 2 compliant will work with a management system that is only compliant with level 1 as long as there is no dependency on any level 2 features.
The standards do not specifv how exactly the components of an e-learning system are to be implemented. So, for example,: a web server or a browser can carry out the communication with the management system. The content may track communications failures or may use a "fire and forget" approach. There have been many interpretations on how the standards should be implemented. Some vendors have used the syntax of the communication, but changed the semantics. By changing the semantics, the software may fail for systems that interpret the communications. In some cases one vendor's interpretation is in conflict with another vendor's.
US2002/0178181 describes a method in which network-bases pages inco orating media establish learning paths, which pages are accessible to network users collaboratively.
The invention is therefore directed towards simplifying and streamlining operation of LMSs for e-learning.
SUMMARY OF THE INVENTION
According to the invention, there is provided an e-learning gateway comprising a gateway server comprising: a first interface for communicating with learning management systems; a second interface for communicating with student computers; and a third interface for communicating with learning content servers.
The gateway server also comprises a work flow controller for directing flow of content and of course tracking messages between a configuration of content server, learning management system, and student computer for a learning session.
In one embodiment, the work flow controller dynamically generates a work flow definition for a session.
In one embodiment, the gateway stores work flow templates and dynamically populates selected templates to generate a work flow definition.
In another embodiment, the gateway populates selected templates according to content routing and progress message routing data for the session.
In another embodiment, the gateway further uses progresses filtering data to populate said templates.
In one embodiment, the gateway server downloads a work flow progress definition to the student computer for a session, in a format for execution by the student computer.
In one embodiment, the work flow definition is downloaded for execution by a student computer browser.
In one embodiment, the work flow controller uses received content meta data and content source data to generate the work flow definition.
In one embodiment, the templates have the form of a hierarchy of text documents containing program script and tags.
In one embodiment, the work flow controller uses received data to fill placeholder tags in the template.
In one embodiment, the gateway comprises a registration program for execution on a learning management system and for communication with the gateway server for registration of the learning management system, and meta data for courses are downloaded by the server to the learning management system upon registration.
In one embodiment, the gateway server maintains a database of course meta data for registered content providers, and this meta data is downloaded to the learning management system upon registration.
In one embodiment, the gateway server executes a work flow service which downloads a work flow definition in response to a registered learning management system request and upon verifying the learning management system.
In one embodiment, the downloaded work flow definition is executed by a student browser and the browser uses the definition to access a content server to retrieve content.
In one embodiment, the gateway comprises a content session and authentication switch executing on a content server registered with the gateway server, said switch receiving a content request from the student browser and automatically accessing the gateway server for authentication of the browser.
In a further embodiment, the gateway server comprises a proxy for routing content requested from a content server by the student browser to the browser, and for receiving and managing course tracking data generated by the content as it executes on the student browser.
In one embodiment, the gateway server downloads a program to the browser for performing course progress filtering and adaptation operations which a browser can not perform.
In one embodiment, the switch can direct routing of the content to the browser either directly or via the gateway server according to the work flow definition.
DETAILED DESCRIPTION OF THE INVENTION
Brief Description of the Drawings
The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which: -
Fig. 1 is a block diagram showing communication links between an e-learning gateway of the invention and other systems;
Fig. 2 is a flow diagram for generation and handling of work flows;
Figs. 3 and 4 are work flow diagrams; and
Fig. 5 is a detailed representation of the gateway functionality.
Description of the Embodiments
Referring to Fig. 1 an e-learning gateway server 1 communicates, via the Internet, with multiple e-learning course/content provider systems 2, 3, and 4, and with multiple learning managements systems (LMSs) 10, 11, and 12. The LMSs 10, 11, and 12 in turn are linked via intranets with student computers 13, 14, and 15 respectively. The student computers 13, 14, and 15 are linked with the gateway server 1 and with the servers 2, 3, and 4 via the Internet. There is therefore full cross- connectivity for all of the systems shown in Fig. 1.
The full gateway of the invention comprises the gateway server 1 and also software components installed in the content providers 2,3,and 4 and in the LMSs 10,11, and 12.
The gateway 1 performs work flow control for progress of courses involving combinations of the systems 2- 4, and 10-15 shown in Fig. 1.
Referring to Fig. 2 the work flow control implemented by the gateway is indicated generally by the numeral 20. In step 21 various inputs are received including:
Student data, such as LMS identifier, name, authentication data for content sites, and progress data for the activated training, audio/video preferences, and preferred training style. Company profile data such as technical support details, content site rights/limits, workflow and display preferences, limitations, security restrictions (e.g. firewall rules), controls for access to training content and training modes/options, content runtime requirement fulfilment criteria (e.g. plug-in installation sources/limitations).
Content Meta data, such as identifiers (production and developer), description, name, version, vendor, display preferences, training objectives and structure, training durations, tracking preferences, digital rights/licensing limits, training
styles, training depth, complexity, media types, keywords, runtime technology requirements and default fulfilment criteria associated training modes/options.
Content source, location, portal, and repository details such as authentication requirements and availability of content adapters in the content domain.
LMS meta data, such as location, domain, name, version, tracking preferences (e.g. compliance levels), availability (visibility to the Internet), usability details (e.g. window creation on launch), and implementation details (e.g. uses Java applet/JavaScript for JSAPI, runtime technologies).
The gateway then in step 22 uses this data to retrieve templates for content routing, progress routing, and progress filtering. These templates have the format of a hierarchy of text documents containing JavaScript and data tags. The templates are dynamically selected and filled based on the templates higher in the "execution" hierarchy.
In step 23, the gateway modifies the templates. The templates consist of JavaScript and tags (processing tags and data placeholders). Each template is processed by following the processing tags (flow control) and using the incoming data (student/ content/LMS) to fill the data. In many cases the raw data is used to fill a tag, and some data placeholder tags require some manipulation. The manipulation is based on simple processes.
In step 24, the gateway directs execution of the work flow to perform its required operations. As indicated by the decision step 25, this is repeated for every required work flow for a course. The modified work flows are then downloaded by the gateway server 1 to the student browser in step 26, which then uses the work flow to direct interfacing of the various systems to complete a course. This may include call-back to the gateway server integration services to receive a sub-workflow or data. Workflows may call to content adapters which in turn may call-back to the server (i.e. the workflow "clients" can come from multiple sources).
Example workflows are shown in Figs. 3 and 4. The name "Connect" denotes the gateway server 1. Fig. 3 shows a sample of how one of the styles of content is handled. In this case the content is tracked on a content server 2, 3, or 4, using CGI or a similar technology. The course progress data is routed through the gateway server 1 and onto the Connect client 13, 14, or 15 and finally to the management system 10, 11, or 12. In this case the gateway serverl emulates the management system to the content.
Referring to Fig. 4 another workflow is illustrated. This diagram shows a sample of how another of the styles of content is handled. In this case the content is tracked in the student's web browser by cookies, scripting, plug-ins/active control(s) and/or an applet. The progress is communicated to the student computer (client) and on to the management system. In this case the client emulates the management system to the content server. Any time that the gateway 1 is involved in the communications there may be filtering or transformations that takes place in order to emulate the management system or content.
Referring to Fig. 5, the detailed architecture of the gateway 1 is shown. The components and their roles/functionalities are set out below. The word "Connect" is a name for the gateway 1.
After installation, the gateway is present in three domains, namely a gateway server 1 domain 40, an LMS domain 50, and a content domain 60. The various components 41-48 of the gateway domain, 51-54 of the LMS domain, and 61 of the content domain are best described by way of the manner in which they operate.
A customer registration function 51 accesses a content client 42, which in turn accesses a database 41 in order to download a HTML page with JavaScript program code. These transmit to the student's browser launch pages to provide a starting point for registration of an LMS with the gateway 1. A content installation function 52 then can access a download content meta data function 43. The latter instructs a meta data generator 44 to retrieve course meta data from the database 41. An example of meta data is a chapter listing for a course. The content installation function 52 will regularly
update the meta data to a store 53 to ensure that it is up to date, but not every time a course is played by the student.
In course run time, a student selects from the LMS-stored meta data using the Connect client page 54. This function then accesses a work flow service function 45, which is the server-based function which generates the work flow in a manner as described above with reference to Fig. 2. However, before providing a work flow to the student computer, the WF service 45 performs customer authentication using data retrieved from the database 41. Upon authentication, the student computer browser receives the work flow from the WF service 45. The student computer browser then makes the links with the relevant content server. A content session/authentication switch 61 in the content server receives the request and in turn accesses a content domain switch 46 of the gateway server. This again authenticates the browser and accesses the meta data on the database 41. It also routes content originating in the relevant content server to the student browser. In doing so it acts as a proxy, in which the actual content originates in the content server, but it routes it so that tracking data (generated by content programs provided by the content server) is routed to the gateway server 1.
The Connect HACP URL 47 performs progress tracking in accordance with the AICC specification for HTTP CMI Protocol. The version of the protocol to be used and the level of compliance is automatically determined when the session is created based on the LMS, and student and content metadata associated with the session.
The Connect client applet 48 performs client-side workflow operations that cannot be processed directly by the browser (these include progress adaptation/filtering, content routing/client-side web server instance, http response parsing/redirection, offline progress storage/retrieval, etc.).
It will be appreciated that the gateway is independent of content vendor and learning management system. It has been built to support any AICC/SCORM compliant LMS, whether it is hosted or installed behind a firewall. If the student can access a standards-based LMS, then the gateway 1 can track the content.
Content is tracked by default in the manner best suited to the content and the LMS, but the tracking method can be changed by a content customer request. The gateway can provide tracking for mute content. Basic tracking is a standards-compliant tracking method used to capture progress when none is communicated by the content. Basic tracking includes: Elapsed Time (time spent in the content over a number of sessions), Progress Status (not accessed, incomplete)
The gateway can also provide a progress editor that can be used by administrators/students to modify their progress. This is generally only enabled for use on basic tracking units. The gateway 1 organizes mute content into trackable WBT units. Tests can also be created using this service. The gateway 1 can track proprietary content using basic tracking. Progress from uncontrolled content can be filtered to ensure the highest quality progress tracking.
Progress filtering is the process of taking the progress communicated by content and filling in the gaps. This could be anything from completing of standard protocol to modification of the progress itself to conform to the expectations for the content or LMS.
Any content tracking that is routed through the gateway can be filtered.
The gateway 1 provides a very advantageous service for server-driven content. It allows this content to track into an LMS that is not exposed to the Internet. It does this by routing progress through the gateway 1.
For an unsigned client, the gateway 1 directly routes the progress. The progress from a signed client can be sent directly to the LMS or routed through the gateway server 1 (for filtering).
The progress from a JavaScript API client can be sent directly to the LMS or routed through the gateway 1 (for filtering).
The progress from signed JavaScript content can be sent directly to the LMS or routed
through the gateway server 1 (for filtering).
The invention is not limited to the embodiments described but may be varied in construction and detail.