Software framework for progress tracking in classroom environment

Abstract

The invention relates to a software framework for progress tracking in a classroom environment. The present patent application relates to a client-server architecture enabling progress tracking related to assignments generated by teachers. The distribution may include specifying an attachment to which a placeholder is submitted and / or an activity performed by a student that will be part of the distribution. Some activities may be performed using a third-party application that implements at least a portion of a software framework that causes the application to generate progress tracking information provided to a daemon executing in the background of a client device. A daemon and / or client application interacts with one or more web services to enable teachers to utilize progress tracking information. The network service may include a distribution service for generating distributions assigned to a group of students. The network service may also include a progress pipeline including a plurality of services configured to process progress tracking information received from the plurality of client devices.

Description

[0001] This application is a divisional application of the invention patent application with the application date of March 7, 2019, application number 201980016106.1, and invention name “Software framework for progress tracking in classroom environments”. Technical Field

[0002] The embodiments generally relate to a software framework configured to implement various techniques in a classroom environment. More specifically, embodiments of the present invention relate to tracking and reporting information related to the completion progress of an online assignment for multiple students. Background Art

[0003] Since the invention of audio-visual (AV) devices such as televisions, projection systems, and recorders, school districts and teachers have incorporated these devices into their lesson plans to provide information to students in new and interesting ways. Teachers are not limited to textbooks, handouts, and written assignments to impart knowledge. With the advent of the information age, the Internet has opened up a new world of classroom teaching. Now teachers can draw information from a vast array of information resources in order to develop interesting and effective interactive lesson plans.

[0004] However, teachers have limited tools available to them when developing these lesson plans. The article may provide useful background information about a specific subject. However, the teacher may not be able to share this article well with his students. The traditional way to distribute these teaching materials to students is that the teacher can print this article on paper. However, this approach not only causes a waste of resources, but also loses some elements of the interactive elements (e.g., animations, hyperlinks, etc.) of the article presented online. Alternatively, the teacher can send a hyperlink of this article to each of his students via email for the students to read the article at home or on a computing device provided by the school. Although such methods allow students to read the article in the appropriate context to interact with the interactive elements embedded in the article, the teacher can neither track whether each student has opened the hyperlink nor track whether each student has actually read the entire article. Summary of the invention

[0005] Various embodiments related to a client-server architecture are described herein, which implements progress tracking associated with the assignment generated by the teacher. Distribution may include specifying an annex to submit a placeholder and / or an activity performed by a student as a part of the assignment. Some activities may be performed using a third-party application that implements at least a portion of a software framework that enables the application to generate progress tracking information provided to a daemon executed in the background of a client device. The daemon and / or client application interact with one or more network services to enable the teacher to utilize the progress tracking information. The network service may include a distribution service for generating a distribution assigned to a group of students. The network service may also include a progress pipeline that includes a plurality of services configured to process the progress tracking information received from a plurality of client devices.

[0006] In some embodiments, the client device includes a processor, a memory, and a display. The memory may include an operating system, a client application, a daemon process, and one or more third-party applications, such applications including at least one progress application that implements at least a portion of a software framework. The software framework enables the progress application to generate progress tracking information associated with one or more contexts provided by the progress application to the client application and / or the daemon process. The context typically defines the structure of at least a portion of the progress application so that the client application can define activities that can be completed by students within the progress application.

[0007] In some embodiments, the daemon process is executed as a background process and is configured to receive progress tracking information from one or more applications, filter the progress tracking information, store the progress tracking information in a remote database, generate metadata associated with the progress tracking information, and transmit the metadata to at least one service. The daemon process can also implement a synchronization mechanism that reconciles a version of a resource stored locally on a client device with a version stored in a remote database. The synchronization mechanism enables a resource to be accessed on two or more client devices.

[0008] In some embodiments, the software framework causes the progress application to generate an API call that includes progress tracking information that is transmitted to the daemon process. The daemon process can be configured to filter the progress tracking information based on whether progress tracking is enabled or disabled for one or more progress applications. Alternatively, the daemon process can be configured to filter the progress tracking information based on a list of activity contexts.

[0009] In some embodiments, the remote database is a network-based storage service distributed into a plurality of regions storing different data, the scope of each region being limited to any combination of at least one of an organization identifier, a class identifier, a user identifier, a context identifier, or a distribution identifier. Metadata corresponding to the progress tracking information is generated by the daemon process and transmitted to the progress pipeline. The metadata includes a reference to the progress tracking information in the remote database and at least one of the class identifier, the distribution identifier, the user identifier, or the context identifier.

[0010] In some embodiments, the progress pipeline includes multiple services structured in a pipeline architecture. The progress pipeline may include an accessible service configured to: receive metadata corresponding to progress tracking information; dereference a user identifier included in the metadata by replacing the user identifier with a directory service identifier or an internal identifier; determine whether progress tracking is enabled or disabled for one of the user identifier, the directory service identifier, or the internal identifier; and filter the metadata based on the determination. The progress pipeline may include an enrichment service configured to: enrich the metadata using at least one of an organization identifier, a directory service identifier, a user identifier, or a distribution identifier. The progress pipeline may include an aggregator service configured to: retrieve a subset of metadata corresponding to a tracking window from a distributed file system including at least one log node, generate a data structure including a subset of metadata associated with a specific organization identifier included in the subset of metadata, store the data structure in a memory, and push a reference corresponding to the data structure into a queue. The progress pipeline may include an exitable service configured to: process a data structure to generate sorted metadata based on at least one of a class identifier, a distribution identifier, a context identifier, a user identifier, a directory service identifier, or an internal identifier. The progress pipeline may include a deposit service configured to: associate progress tracking information with a progress identifier associated with one of the user identifier or the directory service identifier; and store the progress tracking information and the progress identifier in a network-based storage service.

[0011] The client-server architecture and / or software framework (alone or in combination) can enable teachers and students to interact using interactive lesson plans that include the functionality of one or more third-party applications to enhance the learning experience. Other aspects and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings that illustrate by way of example the principles of the described embodiments.

[0012] The present invention is provided for the purpose of summarizing some exemplary embodiments only, so as to provide a basic understanding of some aspects of the subject matter described herein. Therefore, it should be understood that the above-mentioned features are only examples and should not be interpreted as narrowing the scope or essence of the subject matter described in the present invention in any way. Other features, aspects and advantages of the subject matter described herein will become apparent through the following detailed description, drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The present disclosure will be more easily understood through the following detailed description in conjunction with the accompanying drawings, in which like reference numerals represent like structural elements.

[0014] Figure 1 A network environment designed to operate within a classroom environment is shown according to some embodiments.

[0015] Figure 2 A client-server architecture implemented to enable progress tracking for client devices in a classroom environment is shown according to some embodiments.

[0016] Figure 3 A graphical user interface of a client application according to some embodiments is shown.

[0017] Figure 4 A client-server relationship between a distribution service and a client application and / or daemon process is shown according to some embodiments.

[0018] Figure 5 A synchronization mechanism implemented by a daemon process according to some embodiments is shown.

[0019] FIG. 6A to FIG. 6E A graphical user interface of a client application according to some embodiments is shown.

[0020] Figure 7 A client-server relationship between a distribution service and multiple client applications and / or daemons associated with multiple students in a class is shown according to some embodiments.

[0021] FIG. 8A to FIG. 8C A graphical user interface implemented by a client application on a client device associated with a student is shown according to some embodiments.

[0022] Fig. 9 A client-server relationship between a submission service and multiple client applications and / or daemons for multiple students in a class is shown according to some embodiments.

[0023] Fig.10A client-server relationship between a progress pipeline and a client application and / or daemon process is shown according to some embodiments.

[0024] Fig.11 Filtering of progress tracking information by a daemon process according to some embodiments is shown.

[0025] Fig.12 A progress pipeline is shown according to some embodiments.

[0026] Fig.13 A client-server relationship between a reporting service and a client application and / or daemon is shown according to some embodiments.

[0027] FIG. 14A to FIG. 14B A graphical user interface of a client application according to some embodiments is shown.

[0028] Fig.15 is a flowchart of a method for tracking student activity on a client device according to some embodiments.

[0029] Fig.16 is a flowchart of a method for processing progress tracking information utilizing one or more services available over a network, according to some embodiments.

[0030] Fig.17 A detailed view of an exemplary computing device that can be used to implement the various apparatus and / or methods described herein is shown in accordance with some embodiments. DETAILED DESCRIPTION

[0031] Representative applications of the methods and apparatus according to the present application are described in this section. These examples are provided only to add context and aid in understanding the described embodiments. Therefore, it will be apparent to those skilled in the art that the embodiments may be practiced without some or all of these specific details. In other cases, in order to avoid unnecessarily obscuring the embodiments, well-known processing steps are not described in detail. Other applications are possible, so that the following examples should not be considered restrictive.

[0032] In the following detailed description, reference is made to the accompanying drawings which form a part of the specification and in which specific embodiments according to the described embodiments are shown by way of example. Although these embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments, it should be understood that these examples are not limiting; other embodiments may be used and modifications may be made without departing from the spirit and scope of the described embodiments.

[0033] Digital classrooms offer new opportunities for students to learn in a rich environment of interactive applications installed on computing devices provided to students. While devices can allow students to interact with online information accessed through a browser or provided through specialized applications, the benefits of these activities are often lost because tracking these activities is difficult. Therefore, new technologies are needed to combine these instructional materials into a unified classroom framework.

[0034] The classroom environment can provide a plurality of devices and applications for teachers and students, which enable teachers to use these applications to assign student activities that can be easily monitored by teachers. Teachers create distributions to assign to students, which combine activities defined by contexts provided by one or more third-party applications that implement the software framework. The third-party applications are configured to track the progress of students completing activities associated with these contexts and provide progress tracking information to the background process of the device. The background process and / or the client application can interact with one or more network services designed to process progress tracking information. The processed progress tracking information can be queried to generate report data for display to the teacher, who can show the progress of each student among the students to whom the distribution is assigned.

[0035] The following references Figures 1 to 17 These and other embodiments will be discussed in detail; however, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for illustrative purposes only and should not be construed as limiting.

[0036] Figure 1 1 shows a network environment 100 designed to operate within a classroom environment according to some embodiments. The network environment 100 includes a plurality of independent and distinct computing devices configured to communicate via a network 150. The network environment 100 includes a server device 110 and a client device 120. Figure 1 As shown, client devices 120 may include, but are not limited to, laptop computers 120-1 and 120-5, tablet computers 120-2, 120-3, and 120-4, and mobile device 120-6. It should be understood that network environment 100 may include other types of client devices 120, such as desktop computers, wearable devices (e.g., smart watches), personal digital assistants, etc.

[0037] The following terms may be used herein. A class is a group of individuals who meet regularly to be taught a particular subject or activity. A class may include one or more teachers and a number of students enrolled in the class. A classroom environment is a set of related devices utilized by a group of users associated with a class. A school is an administrative collection of multiple classes taught by a group of teachers. A school district is an organization that manages one or more schools.

[0038] In some embodiments, the teacher distributes the materials to students in the class using one or more devices. Figure 1 As shown, the teacher can create materials for students using a laptop computer such as client device 120-1 or a tablet computer such as client device 120-2. In some embodiments, the laptop computer and / or tablet computer include an application configured to create interactive assignments for students. These assignments may include obtaining links to materials available through the network 150, such as connecting a website accessible from the first server device 110-1 or obtaining a hyperlink to a document stored on the second server device 110-2. The application can also enable the teacher to easily assign the assignment to students. Students can access the assignments and view the materials included in each assignment using tablet computers such as client devices 120-3 and 120-4, laptop computers such as client devices 120-5 and / or mobile devices such as client devices 120-6.

[0039] In some embodiments, the third server device 110-3 hosts one or more services utilized by applications included on various client devices 120. For example, the third server device 110-3 may host a service for uploading a data structure or file that defines an allocation allocated to a network-based storage resource. For another example, the third server device 110-3 may host a service that tracks which client devices 120 are registered to a specific classroom environment. For another example, the third server device 110-3 may host a service that tracks the progress of each student corresponding to a specific allocation. In some embodiments, the services utilized by the application may be hosted on more than one server device 110. In addition, the services may be hosted by different service providers. For example, the first server device 110 maintained by the first service provider may be configured to host a network-based storage service, and the second server device 110-2 maintained by the second service provider may be configured to host a school management service.

[0040] The following describes a software framework for applications executed by various client devices 120 within a classroom environment. Additionally, the following describes various services utilized by the applications described herein and hosted on one or more server devices 110.

[0041] Figure 2A client-server architecture 200 implemented to enable progress tracking of a client device 120 in a classroom environment is shown according to some embodiments. The client-server architecture 200 includes a client application 205 implemented on the client device 120 and configured to interact with a plurality of services implemented on the server device 110 accessible via the network 150. The client-server architecture 200 enables an instructor to create assignments that include rich, interactive materials provided by one or more third-party applications installed on the client device 120, and can integrate seamless tracking of progress, enabling the instructor to monitor student effort while staying in sync with the assignment in the classroom.

[0042] In some embodiments, the client application 205 is a binary executable program configured to be executed by a processor included in the client device 120. The binary executable program can be designed to work within a specific operating environment, such as a target hardware platform designed to execute a target operating system. Therefore, the client application 205 can be implemented using multiple versions of source code compiled for different operating environments. For example, a first version of the client application 205 can be designed for a laptop computer 120-1, and a second version of the client application 205 can be designed for a tablet computer 120-2.

[0043] In some embodiments, the client application 205 is designed to connect to one or more services through the network 150. Services may include, but are not limited to, distribution services 220, submission services 230, school management services 240, schedule pipelines 250, identity services 260, and reporting services 270. The client application 205 may be configured to access services via application programming interfaces (APIs) implemented by these services. For example, network-based services may use simple object access protocols (SOAP) or representational state transfer protocols (REST) ​​to implement APIs that enable the client application 205 to access and / or operate resources associated with the services. The API enables the client application 205 to transmit data to the service and / or receive data from the service. API calls may also enable the service to perform various operations and / or use additional API calls to call additional services.

[0044] In other embodiments, the client application 205 is a web-based application displayed within a browser of a client device 120. The client application 205 may include a series of resources (e.g., Hypertext Markup Language (HTML) documents, images, scripts, etc.) requested from a server associated with a website. The browser receives the resources and parses the resources to display a representation of the website on the display device 120. Thus, the client application 205 is platform-independent because the client application 205 is displayed on multiple different client devices 120 running different operating systems.

[0045] In some embodiments, client application 205 interacts with one or more services through API gateway 210. API gateway 210 is implemented by server device 110 and redirects API calls received from client device 120 to various services in client-server architecture 200. In other embodiments, API gateway 210 is omitted or selectively bypassed, and client device 120 transmits API calls directly to the services.

[0046] In some embodiments, the client application 205 enables teachers to create distributions for classes. A distribution refers to a file or data structure that includes information related to a distribution that is intended to be issued to students in a class. A distribution may include multiple fields, including a distribution identifier, a distribution title, a distribution body including text-based instructions for students on how to complete the distribution, a deadline for the distribution, and a list of attachments associated with the distribution. The distribution may be created and stored locally on a specific client device 120. Attachments may include files (e.g., documents, images, videos, etc.), placeholders for students to hand in files, and activities that students are to complete as part of the distribution. The activity is performed using a third-party application that implements a part of the class toolkit software framework. Examples of the activity may include, but are not limited to, reading a chapter of an e-book or textbook, taking a test or answering a set of questions, tracking the time spent performing tasks such as playing interactive games or conducting electronic experiments, etc.

[0047] In some embodiments, the client-server architecture 200 includes a distribution service 220. The distribution service 220 is configured to manage distributions. In some embodiments, the distribution service 220 is configured to synchronize distributions created on one client device 120 with distributions created on another client device 120 to enable teachers to work on multiple devices. In some embodiments, the distribution service 220 is configured to enable distributions to be published to a list of students. Publishing a distribution refers to making the information in the distribution available for students to view on separate client devices 120, as well as handling various back-end operations related to attachments to the distribution.

[0048] In some embodiments, the client-server architecture 200 may also include a submission service 230. A submission refers to a placeholder for a file or data structure that indicates that the student is directed to create a file or data structure to turn in in order to complete an assignment. The student may create a file or data structure and submit the file or data structure to the submission service 230 to satisfy the requirements for completing the assignment.

[0049] In some embodiments, the client-server architecture 200 may also include a school management service 240, which is configured to manage the management information related to the class structure of the school district. For example, the school management service 240 can maintain a record indicating which teachers are assigned to each class in a plurality of classes. The record may also indicate which students are registered in each class in a plurality of classes. Each teacher or student may be assigned a teacher identifier or a student identifier respectively. Each class created by the school district may be associated with a class identifier. A separate record may then be created for each class identifier, which lists the list of student identifiers of the students registered in the class. In some embodiments, a related database associates a teacher identifier and / or a student identifier with a class identifier in one or more tables. A related database may be queried using structured query language (SQL) or some other types of query languages ​​to return information identifying each class structure.

[0050] In some embodiments, the school management service 240 includes an administrative interface that enables a school district administrator to create classes and specify students enrolled in the class. The administrative interface can be, for example, a web-based interface that requires the administrator to provide credentials to change the roster for each class. In other embodiments, the school management service 240 includes an interface for downloading data from an independent and different school information system that the school district maintains separately from the client-server architecture 200. Classes and rosters can be automatically downloaded from the school information system.

[0051] In some embodiments, the client-server architecture 200 may also include a progress pipeline 250. The progress pipeline 250 provides a secure architecture for managing information related to progress tracking as students complete assignments described in a distribution published by an instructor. The student's client device 120 may include a background process (i.e., a daemon) configured to monitor activities associated with one or more third-party applications installed on the client device 120. The daemon tracks the student's progress in completing the assignments specified in one or more published distributions and transmits information related to each student's progress to the progress pipeline 250. The progress pipeline 250 aggregates and stores the progress information to enable the instructor to view a comprehensive report of one or more students in the class.

[0052] In some embodiments, the progress pipeline 250 is implemented as multiple independent services executed on different server devices 110 and is structured to process progress information in the data stream in a pipelined manner. In other embodiments, the progress pipeline 250 can be implemented using multiple services executed on a single server device 110.

[0053] In some embodiments, the client-server architecture 200 may also include an identity service 260. The identity service 260 enables data associated with a particular client device 120 to be associated with a particular group of people (e.g., a teacher or a student) within a classroom environment. In some embodiments, the identity service 260 associates various user identifiers or device identifiers with directory service identifiers that are limited in scope to the server side of the client-server architecture 200. The use of the identity service 260 protects the integrity of the data by disassociating the personally identifiable information collected by the daemon from any identifier used outside a specific scope (e.g., a classroom environment). Therefore, data such as the score a user receives on a test cannot be tied to other information outside the above scope, such as what type of music the student likes to listen to on a music sharing service provided by the same service provider. Given that most students are minors, the integrity of such personally identifiable information is particularly important, and special considerations may be required when protecting the data of vulnerable users of a certain age group.

[0054] In some embodiments, a directory service identifier is a static identifier associated by a particular service provider with a user of one or more devices. The directory service identifier may be associated with a user identifier used by a client device to associate a user with a particular user account. The directory service identifier may be associated with an external identifier that is associated with a user of a particular user account and exposed to the client device. The directory service identifier may be associated with an internal identifier for a particular user. The internal identifier may be disassociated from the directory service identifier, and then a new internal identifier may be associated with the directory service identifier. In some embodiments, replacing an internal identifier with a new internal identifier may be used to break the association between certain stored data and a particular user or user account without deleting the data from one or more server devices 110.

[0055] In some embodiments, the client-server architecture 200 may also include a reporting service 270 that enables summary data related to the progress of activities completed by multiple students to be compiled and provided to the client device 120 for teacher review. The reporting service 270 may also analyze the progress information received from multiple students to generate statistics related to the progress information. For example, the reporting service 270 may generate statistics related to the number of students who completed a particular activity. The reporting service 270 may also track results related to the activity (e.g., the number of questions in a quiz activity answered correctly, the time to complete the quiz, etc.). In other embodiments, the client application 205 receives report data about each student from the reporting service 270, and the client application 205 aggregates the report data and / or calculates statistics for the class.

[0056] It should be understood that the client application 205 may be configured to interact with some or all of the services described in the client-server architecture 200. For example, the client application 205 may be configured to generate calls to the distribution service 220, the submission service 230, the progress pipeline 250, and the reporting service 270. In some embodiments, the client application 205 is not configured to interact with a subset of services such as the school management service 240 and / or the identity service 260. Instead, other services may generate calls to these services in response to receiving calls from the client application 205.

[0057] Figure 3 300 of the client application 205 according to some embodiments is shown. The GUI 300 can be presented to the teacher on the display 302 of the client device 120. Figure 3 As shown, GUI 300 is displayed on a tablet computer such as client device 120-2. GUI 300 may include a plurality of elements including graphics, text, icons, shapes, input fields, output fields, display areas, and the like.

[0058] In some embodiments, GUI 300 includes a first display area 310, a second display area 320, and a third display area 330. First display area 310 is used to display representations of distributions previously created by a teacher. Second display area 320 is used to display representations of classes associated with a particular teacher. Figure 3 As shown, the first display area 310 occupies a first portion of the pixels included in the display 302 , and the second display area 320 occupies a second portion of the pixels included in the display 302 .

[0059] The first display area 310 includes a header, which indicates that an element 312 represents an independent and different distribution associated with a user account. The distribution can be created by a teacher, an administrator, or an account associated with other roles. In some embodiments, each element 312 is limited by a frame, which includes a title of the distribution, a descriptor of the deadline associated with the distribution, and an indication of the number of students who have completed the distribution. For example, the first element 312-1 is associated with the first distribution assigned for "plants and animals", the deadline of which is March 12 and has been completed by all of the students; and the second element 312-2 is associated with the second distribution assigned for "test preparation", the deadline of which is March 15 and is completed by only seven students in the twenty-two students assigned the second distribution. It should be understood that in other embodiments, element 312 can take different forms. For example, element 312 can omit the deadline and / or completion indicator. Alternatively, element 312 may include information in addition to or in place of the deadline and / or completion indicator. In addition, element 312 may include graphics such as images or icons representing different activities distributed in the distribution. In some cases, the graphics may be animated such as by playing a video or showing a slide show of images attached to the distribution as the background of element 312.

[0060] The second display area 320 includes a header indicating that the element 322 represents an independent and different class associated with a user account of a specific teacher. In some embodiments, each element 322 is defined by a box including a descriptor of the class name and the number of distributions assigned to the class. For example, the first element 322-1 is associated with the "Science A" class, which has two distributions assigned; the second element 322-2 is associated with the "Math A" class, which has three distributions assigned; and the third element 322-3 is associated with the "Math B" class, which does not have the distribution assigned. It should be understood that in other embodiments, the element 322 may take different forms. For example, the element 322 may omit the indicator of the number of distributions assigned to the class. Alternatively, the element 322 may include information in addition to or in place of the indicator of the class name and the number of distributions assigned to the class. For example, the element 322 may include the number of students registered in the class. Additionally, element 322 may include graphics such as an image or a background color coded to indicate a particular subject or department associated with the class.

[0061] In some embodiments, the teacher can use the input interface of the client device 120 to select a particular class (or multiple classes). For example, the teacher can use the touch interface to select an element 322 associated with one of the available classes that is associated with the teacher. When a particular element 322 is selected, the selected element 322 is activated, and the elements 312 in the first display area 310 may be updated to reflect the distribution associated with the class represented by the selected element 322 in the second display area 320. The selected element 322 (e.g., the currently activated element) is highlighted to indicate that the element 322 is active. The highlighting may be achieved by increasing the size of the element, changing the color associated with the element 322 or changing the color or weight of the border of the element 322, displaying a box around the selected element 322, etc. Figure 3 As shown, the first element 322 - 1 is activated and is shown to be larger than the second element 322 - 2 and the third element 322 - 3 .

[0062] It should be understood that in some embodiments, there may not be enough space within the first display area 310 and / or the second display area 320 to present all of the classes and / or all of the distributions assigned to a particular class within the scope of the display 302. In such cases, the user of the client device 205 can use input commands such as touch gestures to display additional elements. For example, an icon indicating that some elements are not displayed can be displayed. The additional elements will be displayed in the first display area 310 or the second display area 320 in response to the user selecting the icon. For another example, when other elements are moved within or removed from a particular display area, the user can use a swipe touch gesture to scroll horizontally to display additional elements.

[0063] The third display area 330 is located adjacent to the top edge of the display 302. The third display area 330 includes elements that enable a user of the client application 205 to log into a user account, generate a new distribution for a particular class, or edit a previously generated distribution stored locally on the client device 120 and / or remotely on the server device 110. In some embodiments, the third display area 330 is hidden and can be displayed in response to user input such as by using a vertical swipe touch gesture to unhide the third display area 330.

[0064] The first icon 332 is displayed adjacent to the left side of the third display area 330. The first icon 332, when selected by the user, can cause the client application 205 to prompt the user to enter credentials to log in to the user account associated with the teacher. In some embodiments, the first display area 310 and the second display area 320 are hidden until the user logs in to a specific user account using the first icon 332. In some embodiments, when the client application 205 is started, a separate interface is displayed to the user, which prompts the user to enter credentials to log in to the user account. Once the user successfully logs in to the specific user account, the GUI 300 is only displayed on the display 302. The first icon 332 can then be used to exit the user account and / or log in to a different user account.

[0065] A second icon 334 is displayed adjacent to the right side of the third display area 330. The second icon 334, when selected by the user, may cause the client application 205 to create a file or data structure in the file system of the client device 120 to store information related to the new distribution. In some embodiments, the new file or data structure is automatically associated with the active class selected in the second display area 320. The teacher can then use a different GUI to add information to the file or data structure, which will be referred to below. FIG. 6A to FIG. 6E Describe in more detail.

[0066] A third icon 336 is displayed adjacent to the right side of the third display area 330. The third icon 336, when selected by the user, can cause the client application 205 to retrieve information stored in a file or data structure for a previously generated distribution. In some embodiments, one of the elements 312 in the first display area 310 is activated, either automatically based on selection criteria or manually in response to input provided by the user. For example, an element 312 to be activated can be automatically selected based on a minimum difference between a current date and a due date for a single distribution among all distributions stored for a particular class when the element 322 representing the class is activated. Alternatively, an element 312 to be activated can be manually selected in response to a touch gesture input (e.g., a tap input) in an area of ​​the display 302 corresponding to a particular element 312. Although in Figure 3 , but the selected element 312 (eg, the currently activated element) within the first display area 310 may be highlighted to indicate that the selected element 312 is active. In response to selecting the third icon 336, the following reference FIG. 6A to FIG. 6E A different GUI that may be displayed by the client device 120 and populated with data from a file or data structure associated with the active element 312 is described in greater detail.

[0067] In some embodiments, first display area 310 includes representations of distributions being prepared and distributions that have been published to a list of students. In some cases, element 312 may include an indication of whether the distribution represented by element 312 has been published or has not yet been published (i.e., still being prepared by the teacher).

[0068] It should be understood that the above and Figure 3 The GUI 300 shown is merely an exemplary embodiment of a GUI designed for the client application 205. In other embodiments, the GUI for the client application 205 may take other forms. The appearance and user experience of the GUI may also correspond to standard display elements associated with a specific operating system or target environment. In addition, in other embodiments, the client application 205 is a web-based application displayed in a browser of a client device 120. In such embodiments, the GUI 300 may include multiple hypertext markup language (HTML) elements, which are included in one or more HTML documents. The representation of such elements may depend on the specific implementation of the browser application in the client device 120, and in some cases, on the user preferences associated with the browser application.

[0069] Figure 4 The client-server relationship between the distribution service 220 and the client application 205 and / or daemon 440 according to some embodiments is shown. The distribution service 220 provides a way for teachers to create distributions and assign the distributions to a list of students enrolled in a class associated with the teacher. As described above, the client application 205 is configured to prompt the user to provide credentials associated with a user account. If the user account is associated with a teacher, the client application 205 enables the teacher to generate files or data structures for the distribution within the memory 420 of the client device 120. In some embodiments, these files or data structures can be synchronized to a network-based storage service, which enables the teacher to access information related to the distribution from multiple client devices 120.

[0070] like Figure 4 As shown, the client device 120 includes a processor 410, a display 302, and a memory 420. The memory 420 includes an operating system 430, a client application 205, a daemon 440, and a local database 445. The daemon 440 is a background process that implements an API that enables the client application 205 to communicate asynchronously with the daemon 440 to perform certain tasks. One of these tasks operates to create a file in the local database 445.

[0071] In some embodiments, the daemon 440 maintains a local database 450. In some embodiments, the teacher can use the client application 205 to create new files or data structures for distribution. The client application 205 requests the daemon 440 to create files or data structures for distribution in the local database 450 maintained by the daemon 440. The teacher can use the GUI 600 to populate the files or data structures for distribution, as described below with reference to FIG. 6A to FIG. 6E Discuss in more detail.

[0072] In some embodiments, the daemon 440 is configured to synchronize files or data structures in the local database 450 to a remote database 460. The remote database 460 may be a distributed database implemented on multiple server devices 110, such as a cloud-based database service. The daemon 440 interacts with the remote database 460 to synchronize files or data structures in the local database 450 with remote versions of the files or data structures so that the files or data structures can be accessed and / or modified using multiple client devices 120. This will be described below with reference to the remote database 460. Figure 5 Describe the synchronization mechanism in more detail.

[0073] Once the distribution has been synchronized to the remote database 460, the teacher can switch to a different client device 120 using another version of the client application 205 and use the new client device 120 to access the version of the distribution stored on the remote server 110. Any changes to the local copy of the resource stored on the new client device 120 will be synchronized to the remote database 460 to update the version of the distribution on the remote database. These changes are then pushed to the client application 205 on the previous client device 120 to update the local copy of the resource in the local database 450 on the initial client device 120.

[0074] For example, a teacher may open a client application 205 on a laptop computer 120-1 and create a local version of a distribution stored in the memory of the laptop computer 120-1. The daemon process 440 on the laptop computer 120-1 transfers a copy of the local version of the distribution to the remote database 460 to synchronize the distribution with the distribution version stored in the remote database 460. The teacher then opens a separate client application 205 on a tablet computer 120-2 and provides credentials for the teacher's user account. Opening the client application 205 on the tablet computer 120-2 causes the daemon process 440 to download the remote version of the distribution stored on the remote database 460 to the memory of the tablet computer 120-2, where the client application 205 on the tablet computer 120-2 can access the local copy of the distribution and modify the local copy of the distribution in the memory of the tablet computer 120-2. Any modifications to the local copy of the distribution can be synchronized back to the remote database 460 so that the version of the distribution stored on the remote database 460 is up to date. The next time the teacher opens the client application 205 on the laptop 120-1, the client application 205 will cause the daemon 440 to request the current version of the distribution from the remote database 460, which will transfer the version of the distribution stored on the remote database 460 to the daemon 440 in the laptop 120-1 to be stored in the memory of the laptop 120-1 as a local version of the distribution.

[0075] In some embodiments, the distribution service 220 is implemented as an instruction set stored in a memory of the server device 110, which is configured to be executed by a processor of the server device 110. The distribution service 220 manages the distribution of distributions between the client devices 120 associated with the teacher and the students. In some embodiments, the distribution service 220 uses a remote database 460 to implement the distribution of distributions. The distribution service 220 creates regions 465 in the remote database 460. The scope of each region 465 is a specific class. Alternatively, the scope of each region 465 is a group of student groups. Each class associated with a teacher can be associated with different groups of students.

[0076] The teacher can create a distribution in the local database 450 of the client device. The distribution is synchronized to the personal area 465-1 for the teacher in the remote database 460. Once a particular distribution is prepared and ready to be assigned to a group of students, the teacher can publish the distribution using the client application 205 to assign the distribution to the group of students. The client application 205 requests the distribution service 220 to publish the distribution. The distribution service 220 then causes a copy of the distribution to be copied to a new area 465-2 in the remote database 460, the scope of which is the group of students specified in the distribution. Each of the students within the scope of the new area 465-2 subscribes to the new area 465-2, causing the daemon 440 in the client device 120 controlled by each of the students in the group of students to synchronize a copy of the published distribution to the local storage of the client device 120 of the student.

[0077] It should be understood that the distribution service 220 also generates a distribution identifier that can be used to identify the distribution resources stored in the remote database 460. In some embodiments, the distribution identifier is generated when the distribution is published. In other embodiments, the distribution identifier is generated when the distribution is created. The resources for the distribution are then copied to the new area 465-2 and deleted from the teacher's personal area 465-1 when the distribution is published.

[0078] Figure 5 4 shows a synchronization mechanism implemented by the daemon process 440 according to some embodiments. Figure 5 As shown, the daemon 440 is configured to interact with a database service 510 that provides a front end for a remote database 460 via the network 150. The database service 510 can be implemented on the server device 110. In some embodiments, the remote database 460 is limited to the scope of a specific organization or school district. Therefore, all of the information stored in the remote database 460 is used for a specific school district. In such embodiments, the database service 510 is configured to manage multiple remote databases 460 of different organizations or school districts. In various embodiments, the remote database 460 is a cloud-based distributed database service managed by a service provider.

[0079] In some embodiments, database service 510 is configured to store files in multiple different regions 465 implemented in remote database 460. Each teacher and / or student in the school district can be assigned different regions 465 as personal regions in remote database 460. This personal region 465 can store files or data structures associated with a specific user account. In addition, each class created by the school district can be assigned a class region 465 to share resources with all students and teachers associated with the class. In an alternative embodiment, a region 465 can be created for multiple groups of students and / or teachers, and this group of students and / or teachers can be a subset of a class or a subset registered in two or more classes. Class region 465 can be used to publish and distribute to students and / or other teachers associated with a specific class. The scope of region 465 can be an organization, a class, or an individual (e.g., a teacher or a student). Region 465 can also be used for different data.

[0080] In some embodiments, the database service 510 maintains a subscription for each zone 465, which indicates a list of users (e.g., teachers and / or students) within the scope of each zone 465. Whenever a resource within a zone 465 is updated, the database service 510 can push a notification to each of the client devices 120 of users subscribed to the zone 465. The daemon 440 on the particular client device 120 receives the notification and will download the updated resource from the zone 465 to update the local copy of the resource 522 in the local database 450.

[0081] It should be understood that different types of areas can be created to utilize synchronization mechanisms in order to implement some functionality required by one or more services in the client-server architecture 200. For example, areas can be created to store distributions, submissions, bookmarked contexts associated with third-party applications, roster information for a class, progress tracking information, etc. In addition, the scope of each of the above areas can be a single user (i.e., as a personal area) or multiple users. For example, a distribution area 465 is created to store data related to a distribution (e.g., attachments, resources uploaded by students for submission, etc.), and the scope of the distribution area can be a group of students identified in the distribution. A progress area 465 is created to store progress information for multiple students. The scope of the progress area 465 can be a class or a specific distribution published for a class. A roster area 465 is created to store data related to the class structure of an organization. The scope of the roster area 465 can be an organization.

[0082] FIG. 6A to FIG. 6E 1 shows a GUI 600 of a client application 205 according to some embodiments. The GUI 600 can be used to edit information stored in a distribution that a teacher is preparing to distribute to a class. The GUI 600 can be presented on the display 302 of the client device 120. Fig. 6A As shown, GUI 600 is displayed on a tablet computer such as client device 120-2. GUI 600 may include multiple elements including graphics, text, icons, shapes, input fields, display areas, etc. In some embodiments, GUI 600 is displayed in response to the teacher selecting the second icon 334 or the third icon 336 in GUI 300.

[0083] GUI 600 includes a first display area 610, a second display area 620, and a third display area 630. The first display area 610 is used to display information related to a distribution created by a teacher for a particular class or a particular group of students. The second display area 620 is used to display attachments for the distribution. As shown in FIG. 6 , the first display area 610 occupies a first portion of the pixels included in the display 302, and the second display area 620 occupies a second portion of the pixels included in the display 302. The third display area 630 occupies a third portion of the pixels included in the display 302. In some embodiments, the third display area 630 can be hidden and displayed in response to user input such as using a swipe touch gesture so that the third display area 630 appears near the top edge of the display 302.

[0084] like Fig. 6A As shown, the first display area 610 includes an interface to indicate a group of students to whom a distribution will be assigned. The interface shows a label (e.g., "Recipients"), a user interface element 612, and a user interface element 614. The teacher can specify a group of students to whom a distribution will be assigned by typing in the identifiers of the students in the user interface element 612 or selecting the user interface element 614 and selecting the group of students from the list.

[0085] In some embodiments, selecting user interface element 614 causes client application 205 to request roster data for classes associated with the teacher logged into client application 205. The roster data includes identifiers of all students registered in any class associated with the teacher. Client application 205 may request a list of identifiers from school management service 240. Alternatively, client application 205 may retrieve the list of identifiers from local memory 420 of client device 120. For example, the roster service may periodically request roster data from school management service 240, which stores the roster data in roster area 465 of remote database 460. The scope of roster area 465 may be a specific class, and the teacher subscribes to the roster area 465 of those classes associated with the teacher. Therefore, through the synchronization mechanism, daemon 440 will download the roster data to the local database 450 of client device 120, where it can be accessed by client application 205.

[0086] The first display area 610 also includes an interface to indicate the deadline for students to complete the activities attached to the distribution and submit any submissions assigned in the distribution. The interface shows a label (e.g., "Due Date:") and a user interface element 616. The user interface element 616 can display a date (e.g., a time period) for completing the distribution. Selecting the user interface element 616 can cause a representation of a calendar to be displayed, which allows the teacher to select a date.

[0087] The first display area 610 also includes a plurality of text fields that can be edited by the teacher to change the title and body of the distribution. Fig. 6A As shown, the teacher has assigned the title "Plants and Animals" to the distribution and has written the set of instructions provided to the students on how to complete the assignment.

[0088] The second display area 620 includes a pair of user interface elements referred to as a first icon 622 and a second icon 624. The teacher can select the first icon 622 to add a placeholder for the submission to the distribution. The teacher can select the second icon 624 to add an activity to the distribution. Any attachments to the distribution can be listed below the first icon 622 and the second icon 624. Fig. 6A As shown, there is no placeholder for the submission and no activity currently attached to the distribution.

[0089] like Figure 6B As shown, the submitted placeholder is attached to the box 640 that fills the second display area 620 with multiple user interface elements at the distribution. For example, the first user interface element 642 enables the submission option to be edited, the second user interface element 644 displays the information related to the submission, the third user interface element 646 enables the user to display more detailed information about the submission, and the fourth user interface element 648 enables the user to rearrange the attachment to the distribution or delete (e.g., cancel the attachment) submitted placeholder from the distribution. In some embodiments, the second user interface element 644 includes a thumbnail of the representation of the submitted resource and the text next to the thumbnail, and the thumbnail provides information related to the submission. For example, the text can indicate the title of the submission and the type of resources to be generated for the submission. It should be understood that the information can be omitted or additional information can be included to replace the information described herein.

[0090] return Fig. 6A , selecting the second icon 624 causes the client application 205 to display an interface including a user interface element that enables the instructor to attach an activity to the distribution. Types of activities may include activities performed using third-party applications, activities performed by viewing or editing attachments, activities performed by viewing network resources associated with bookmarks or links within a browser application, and activities performed by viewing multimedia files (e.g., images, videos, etc.).

[0091] like Figure 6C As shown, a box 650 may be displayed in response to a user selecting the second icon 624 in the GUI 600. The box 650 includes a first user interface element 652 that enables the teacher to associate an application activity with a distribution. For example, the third-party application may be configured to present a quiz to a student and prompt the student to answer questions included in the quiz. In another example, the third-party application may provide an interactive course for the student, which includes instructions for the student to follow to perform a task (e.g., write source code for a program, play a game, match images with words in a foreign language, etc.). In another example, the third-party application may present the text of an e-book or textbook to the student for the student to read one or more portions of the e-book or textbook.

[0092] Box 650 includes a second user interface element 654 that enables the teacher to attach a file for distribution. The file may include a document, a spreadsheet, a presentation (e.g., a slide deck), source code, or any other type of file that can be viewed with an application on the client device 120. Attached files enable the teacher to distribute materials that are typically read or viewed by students. In some embodiments, the teacher can specify whether all students in the class share a single file (referred to as a collaboration option), or whether to share a duplicate version of the file (e.g., a copy) with each student individually. The teacher can also specify permissions associated with the file, making the attached file read-only or allowing students read-write access to edit the file.

[0093] Box 660 includes a third user interface element 666 that enables the teacher to attach a bookmark or link to the distribution. A bookmark or link refers to a hyperlink that specifies a uniform resource locator (URL) of a resource that can be accessed through a network such as the Internet. The link can enable students to view a website that can be related to the course.

[0094] Box 650 includes a fourth user interface element 658 that enables the teacher to attach a multimedia file to the distribution. The multimedia file may include a picture, a slide show, a video, or other type of multimedia such as virtual reality data or a three-dimensional model. The student can then view the multimedia file using an application such as an image viewer application installed on the client device 120.

[0095] When the user selects the first user interface element 652 to attach an activity associated with a third-party application to the distribution, frame 650 may be replaced with frame 660, such as Fig.6D Block 660 provides the teacher with the ability to select a third party application from a list of applications to use for the activity.

[0096] In some embodiments, frame 660 includes first user interface element 662 to select any application from the list of available applications. However, in some cases, some third-party applications can implement at least a portion of the class toolkit software framework, and at least a portion of the class toolkit software framework enables the third-party application to provide progress data to one or more services, for tracking the progress of the student who completes the activity in the third-party application. These third-party applications that implement at least a portion of the class toolkit software framework may be referred to as progress applications in this article. The progress applications that implement at least a portion of the software framework can be listed separately in each user interface element below the first user interface element 662. For example, the second user interface element 664 enables the teacher to attach activities to the first progress application, the third user interface element 666 enables the teacher to attach activities to the second progress application, and the fourth user interface element 668 enables the teacher to attach activities to the third progress application.

[0097] In some embodiments, the third-party application implements at least a portion of a class toolkit software framework, which provides a method for building interactive features in the third-party application. For example, the class toolkit software framework enables software developers to define a context associated with the application. As used herein, context refers to metadata describing the structure of the application. For example, the context of chapters, sections, pages, problem sets, and similar structures in the electronic textbook can be used to describe the electronic textbook. Generally speaking, context definitions enable metadata to be defined for third-party applications.

[0098] The context also enables tracking of the progress of activities within the application. For example, referring back to the electronic textbook example, a teacher may define an activity related to reading a chapter of a textbook. The context enables the teacher to specify the specific chapter or section in the electronic textbook that the teacher wants to assign when defining an activity. Thus, when specifying an activity using the GUI 600, the client application 205 may query the context to determine which activities may be completed within the third-party application.

[0099] In some embodiments, the teacher can manually search the list of available contexts associated with one or more third-party applications and select a set of contexts that the teacher wants to assign to each distribution. The set of contexts can be saved in memory 420 and associated with the client application 205 so that the teacher can attach activities associated with those contexts to the distribution.

[0100] In other embodiments, each progress application installed on the client device 120 can notify the daemon 440 of the available contexts provided by the progress application. The teacher can use the client application 205 to browse the list of available contexts published by one or more progress applications and select multiple contexts as favorite contexts. For example, by selecting the first user interface element 662 in the box 660, the teacher can browse all available contexts provided by the progress application installed on the client device 120. The teacher can then select a specific context as the teacher's favorite context. The subset of available contexts selected as favorites by the teacher can be stored in the local database 450 of the client device 120. The favorite context selected by the teacher can also be synchronized to the personal area 465 in the remote database 460 of the teacher. Then the additional user interface elements in the box 660 can be displayed together with each user interface element corresponding to the specific favorite context. The teacher can then select the specific favorite context to be attached to the distribution.

[0101] like Fig. 6E As shown, selecting the second user interface element 654 causes the client application 205 to display a box 670 including two user interface elements that enable the teacher to specify options associated with the attached file. In some embodiments, the options include permissions to share the file and whether the file is collaborative. For example, Fig. 6E As shown, user interface element 672 enables the teacher to indicate whether the file is collaborative. This option determines whether the file is shared between multiple users as a single resource, or whether a copy of the file is shared with each user individually. User interface element 674 enables the teacher to change the permissions of the resource for the file. If the resource is read-only, students will not be able to edit the resource; however, if the resource is read-write, students can edit the file.

[0102] It should be understood that Fig. 6E Additional user interface elements not explicitly shown in block 670 may be included in block 670. For example, other user interface elements may enable the instructor to specify files stored in local storage 420 to be attached to the distribution.

[0103] Figure 7 2 shows a client-server relationship between a distribution service 220 and a plurality of client applications 205 and / or daemons 440 associated with a plurality of students in a class according to some embodiments. Figure 7As shown, a class may include L students enrolled in the class, each student having access to one or more client devices 120. As described above, the distribution service 220 is configured to enable a teacher to create and manage distributions using a plurality of different client devices 120 controlled by the teacher. In addition, the distribution service 220 is further configured to facilitate assigning the distribution to client applications 205 included in a plurality of additional client devices 120 associated with a group of students.

[0104] In some embodiments, the teacher may complete preparing the distribution and then publish the distribution to assign the distribution to the group of students for review and completion. The distribution service 220 copies the distribution to a distribution area 465 in the remote database 460, which is scoped to the group of students specified in the distribution. In response to the teacher publishing the distribution, the distribution service 220 notifies each of the client devices 120 associated with the students through various paths 710 that the distribution area 465 in the remote database 460 has been updated. The path 710 can refer to a network path associated with a destination address of a network interface of a particular client device 120.

[0105] The notification may be received by the daemon 440 included in each of the client devices 120. The daemon 440 then downloads the data from the distribution area 465 to the local database 450 in the client device 120. In some embodiments, the distribution service 220 utilizes the school management service 240 to retrieve the user identifiers of the students in the class. The user identifiers may be used to transmit notifications to each of the client devices 120 associated with the students in a given class using a separate notification service.

[0106] In some embodiments, the group of students may be identified by a school management service 240, which is configured to return a list of identifiers of students enrolled in a particular class in response to receiving a request from a distribution service 220. In other embodiments, a roster service may interact with a school management service 240 to create roster data in an organization-scoped roster area 465 of a remote database 460. The distribution service 220 may then access the roster data from the remote database 460, rather than obtaining the roster data directly from the school management service 240.

[0107] In response to a request to publish a distribution, the distribution service 220 may copy the distribution from the personal area 465 that is scoped to the teacher to a distribution area 465 that is scoped to a group of students in the class. Once a copy of the distribution is stored in the distribution area 465, the distribution service 220 transmits a notification of the change to any client devices associated with the students subscribed to the distribution area 465. The daemon 440 associated with the distribution area 465 included in the student's client device 120 will automatically download a copy of the distribution stored in the distribution area 465 to the local memory of the client device 120 in response to receiving the notification from the distribution service 220. The distribution for the student can then be viewed by the client application 205 of the client device 120 so that the student can complete the activities attached to the distribution and / or view the materials attached to the distribution.

[0108] FIG. 8A to FIG. 8C GUI 800 is shown implemented by client application 210 on a client device 120 associated with a student according to some embodiments. The GUI 800 is different from GUI 600. Client application 210 can be configured to display GUI 800 in response to a user logging into a user account associated with a student rather than a teacher. GUI 800 enables a student to view class distributions assigned to a group of students by the teacher of the class.

[0109] In some embodiments, the GUI 800 includes a first display area 810, a second display area 820, and a third display area 830. The first display area 810 is used to display a distribution representation of students assigned to a particular class. The second display area 820 is used to display a representation of the class in which the student is enrolled. Fig. 8A As shown, the first display area 810 occupies a first portion of the pixels included in the display 302 , and the second display area 820 occupies a second portion of the pixels included in the display 302 .

[0110] The first display area 810 includes a header, and the header indicates that an element 812 represents an independent and different distribution assigned to a student in a selected class. In some embodiments, each element 812 is limited by a frame, and the frame includes a title of distribution, a descriptor of a deadline associated with the distribution, and an indication of whether the student has completed the distribution. For example, the first element 812-1 is associated with the first distribution assigned for "plants and animals", and the deadline for the distribution is March 12 and has been completed by the student; and the second element 812-2 is associated with the second distribution assigned for "test preparation", and the deadline for the distribution is March 15 and has not yet been completed by the student. It should be understood that in other embodiments, element 812 can take different forms. For example, element 812 can omit the deadline and / or completion indicator. Alternatively, element 812 can include information in addition to or in place of the deadline and / or completion indicator. In addition, element 812 can include graphics such as images or icons representing different activities assigned in the distribution. In some cases, the graphic may be animated such as by playing a video or showing a slide show of images attached to the distribution as the background of element 812.

[0111] The second display area 820 includes a header, and the header indicates that the element 822 represents the independent and different class registered by the student. Students can select a specific element 822 to view which distributions the teacher has assigned to the student for the class in the first display area 810. In some embodiments, each element 822 is defined by a box, which includes the class name and the descriptor of multiple distributions assigned to the class students. For example, the first element 822-1 is associated with the "Science A" class, and the "Science A" class has two distributions that have not been submitted; the second element 822-2 is associated with the "Math A" class, and the distributions of the "Math A" class have all been submitted; and the third element 822-3 is associated with the "English A" class, and the "English A" class has one distribution that has not been submitted. It should be understood that in other embodiments, the element 822 can take different forms. For example, the element 822 can omit the indicator of the number of distributions assigned to the class students.

[0112] In some embodiments, the student can use the input interface of the client device 120 to select a particular class. For example, the student can use the touch interface to select an element 822 associated with one of the available classes in which the student is enrolled. Upon selecting the element 822, the element 822 is activated, and the elements 812 in the first display area 810 can be updated to reflect the distribution associated with the class represented by the selected element 822 in the second display area 820. The selected element 822 (e.g., the currently activated element) is highlighted to indicate that the element 822 is active. The highlighting can be achieved by increasing the size of the element, changing the color associated with the element 822 or the element 822 border, displaying a box around the selected element 822, etc. Fig. 8A As shown, the first element 822-1 is activated and is shown to be larger than the second element 822-2 and the third element 822-3.

[0113] The third display area 830 is located adjacent to the top edge of the display 302. The third display area 830 includes elements that enable a user of the client application 210 to log into the student's user account. In some embodiments, the third display area 830 is hidden and can be displayed in response to user input such as by using a vertical swipe touch gesture to unhide the third display area 830.

[0114] The first icon 832 is displayed adjacent to the left side of the third display area 830. The first icon 832, when selected by the user, can cause the client application 210 to prompt the user to enter credentials to log into the student's user account. In some embodiments, the first display area 810 and the second display area 820 are hidden until the user logs into a specific user account using the first icon 832. In some embodiments, when the client application 210 is launched, a separate interface is displayed to the user, which prompts the user to enter credentials to log into the user account. Once the user successfully logs into the specific user account, the GUI 800 is only displayed on the display 302. The first icon 832 can then be used to log out of the user account and / or log in to a different user account.

[0115] Selecting a particular element 812 representing a distribution in a particular class causes the GUI 800 to be updated with data representing the distribution, such as Figure 8B A first display area 840 presents information included in a distribution, such as the title of the distribution, the due date of the distribution, an indication of the class to which the distribution is assigned, and instructions included in the distribution assigned by the teacher. A second display area 850 presents information related to any distribution and / or activities attached to the distribution by the teacher.

[0116] Selecting the activity in the second display area 850 will open the activity in different applications. If the activity is the attachment of a specific file type, then the application corresponding to that file type will be opened to view the attachment. If the activity is a bookmark or a link, then the web browser application will be opened, and the resource specified by the URL in the bookmark or the link will be retrieved. If the activity is a multimedia file, then the multimedia application will be opened to view the multimedia file. However, if the activity is associated with a progress application (for example, if the activity is provided with the progress application and is associated as a favorite context by the teacher), then the progress application will be opened to complete the activity. In some embodiments, the progress application implements at least a portion of the class toolkit software framework to track the progress of students when completing the activity.

[0117] like Figure 8C As shown, the GUI 860 of the first progress application is presented to the student on the display 302. The GUI 860 may provide output in the form of information presented as pixel data. Figure 8C As shown, the GUI 860 of the first progress application may provide text and graphics that help students learn a particular topic. The GUI 860 may include elements, some of which may be interactive. For example, a student may select an image of a tree to display more detailed information about the tree. It should be understood that Figure 8C The third-party software shown is shown only for illustrative purposes, and the design of the software is not limited to any particular type of learning software. In fact, the various software that can implement the class toolkit software framework is extensive.

[0118] Fig. 9 4 shows a client-server relationship between a submission service 230 and multiple client applications 210 and / or daemons 440 for multiple students in a class according to some embodiments. Fig. 9 As shown, a class may include L students enrolled in the class, each student having access to one or more client devices 120. Submission service 230 is configured to facilitate management of submissions included in one or more distributions assigned to corresponding groups of students.

[0119] In some embodiments, when a distribution is published that includes a submission placeholder, the placeholder in the distribution indicates that the student is required to turn in a file corresponding to the distribution. Again, the student generates a file for submission using one or more applications on the client device 120. The student can then submit the submission using the client application 205. Alternatively, the client application 205 can create a GUI element that is added to a third-party application (e.g., an application extension) that enables the student to submit the submission from the third-party application.

[0120] In some embodiments, the document created by the student can be synchronized to the personal area 465-1 of the remote database 460 so that the student can access the document from different client devices 120. When the student chooses to turn in the document as a submission, the submission service can copy the document from the personal area 465-1 of the student to the submission area 465-2 of the class, and optionally a specific distribution corresponds to the submission. By moving the document from the student's personal area 465-1 to the submission area 465-2, the teacher can view the document. In some embodiments, the document is also deleted from the personal area 465-1 of the student, and the student is granted read-only access to the copy of the document stored in the submission area 465-2. Therefore, when the document is submitted as a submission, the student can no longer edit the document.

[0121] In some embodiments, the group of students associated with a particular distribution may be identified by a school administration service 240, which is configured to return a list of identifiers of students enrolled in a particular class in response to receiving a request from a submission service 230. In other embodiments, a roster service may interact with a school administration service 240 to create roster data in an organization-scoped region 465 of a remote database 460. Submission service 230 may then access the roster data from remote database 460, rather than obtaining the roster data directly from school administration service 240.

[0122] Fig.10 A client-server relationship is shown between the progress pipeline 250 and the client application 210 and / or daemon 440 according to some embodiments. In order to fully realize the benefits of the Class Toolkit software framework within a classroom environment, a means is needed for tracking the activities of each student using the associated client device 120. The daemon 440 and progress pipeline 250 provide such functionality for any third party application that implements at least a portion of the Class Toolkit software framework.

[0123] like Fig.10 As shown, the client device 120 includes a processor 410 and a memory 420 including software and data. The memory 420 of the client device 120 includes an operating system 430, a client application 210, a daemon 440, and one or more progress applications 1010. The daemon 440 implements an API to communicate with the progress application 1010 via the class toolkit software framework.

[0124] In some embodiments, each of the one or more progress applications 1010 implements at least a portion of a class toolkit software framework for tracking progress associated with one or more contexts provided by the progress application 1010. The class toolkit software framework includes at least one of source code added to the source code of the progress application 1010, source code of a library of functions utilized by the progress application 1010, and a library of compiled functions that can be linked to the source code of the progress application 1010. The software framework provides a function included in the source code of the progress application 1010 that generates an API call to a daemon process 440 executing in the background of the client device 120. The API call includes progress tracking information related to the operation performed by the user in the progress application 1010.

[0125] The software developer may implement API calls within the source code of the progress application 1010 to implement progress tracking functionality within the progress application 1010. For example, in a document viewing application, the source code may be configured to generate an API call that indicates that a user has read a particular page of the document each time the user navigates to a new page. The software developer may also define one or more contexts for the progress application 1010 that specify the structure of the progress application 1010 to allow the instructor to create distributed activities that are attached to the client application 210 that utilize the progress application 1010. Each context is a data structure that defines the structure of the progress application 1010 using a standard language (e.g., predefined keywords) and / or format.

[0126] It should be understood that a single progress application 1010 can be associated with more than one context. For example, a textbook application can be implemented to view multiple textbooks stored in different files or data structures. Different contexts can be defined for each of the different textbooks. Each context can define the specific layout of the corresponding textbook, such as defining the title of the textbook, the author of the textbook, the version of the textbook, the number of chapters in the textbook, the table of contents of the textbook including a description of each chapter of the textbook, a description of the parts included in each chapter, a description of each page included in each part, a description of the problem sets within each chapter or part, etc. The teacher can then use these contexts to select specific activities associated with a specific context and attach these selected activities to the distribution assigned to the students in the class.

[0127] The daemon process 440 is configured to receive an API call from a progress application 1010. The API call may include progress tracking information generated within the progress application 1010. In some embodiments, progress tracking may be enabled or disabled. The daemon process 440 is configured to ignore progress tracking information received from the progress application 1010 when progress tracking is disabled. However, if progress tracking is enabled, the daemon process 440 is configured to process the progress tracking information. In some embodiments, the daemon process 440 aggregates the progress tracking information received from two or more API calls before processing the aggregated progress tracking information received from one or more progress applications 1010.

[0128] In some embodiments, progress tracking may be enabled or disabled for each progress application 1010. Thus, progress tracking may be enabled for a first application while progress tracking may be disabled for a second application. Thus, the daemon 440 is configured to filter out any progress tracking information from any application that has progress tracking disabled, and only process progress tracking information for applications that have progress tracking enabled.

[0129] In some embodiments, upon installation of the client application 210, progress tracking for all progress applications 1010 installed on the client device 120 is automatically enabled. Thus, the user of the client device 120 is required to disable progress tracking for the client device 120 or each third-party application installed on the client device 120 in order to prevent the collection of progress tracking information, which may be referred to as an opt-out policy. In other embodiments, upon installation of the client application 210, progress tracking for all third-party applications 1010 installed on the client device 120 is automatically disabled. Thus, the user of the client device 120 is required to enable progress tracking for the client device 120 or each third-party application installed on the client device 120 in order to allow the collection of progress tracking information, which may be referred to as an opt-in policy.

[0130] The progress tracking information may include, but is not limited to, information identifying actions completed by a user of the client device 120 using the progress application 1010. For example, the progress tracking information may include information indicating that the user has viewed or read a particular chapter of an electronic textbook, completed a number of questions presented to the user via the GUI of the progress application 1010, completed actions such as clicking on a link or interacting with an interactive element of the progress application 1010, and the like.

[0131] Progress tracking information may include personal identification information (PII). This PII may be considered sensitive, so the daemon 440 takes care to protect this information when it is transmitted from the client device 120 to the server device 110. In some embodiments, the progress area 465 of a specific student is used to store the progress tracking information of each student associated with the user account. This progress tracking information is stored and encrypted locally in the memory 420 of the client device 120. This progress tracking information may also be encrypted remotely in the progress area 465 of the remote database 460. The progress tracking information may be encrypted locally or remotely with different encryption keys. In addition, the daemon 440 may be configured to encrypt the progress tracking information transmitted to the remote database 460. The encryption key used for encryption in transmission may be different from the encryption key used locally or remotely. Therefore, various forms of authentication (e.g., biometric authentication, requiring the user to enter a password, etc.) may be used to protect the progress tracking information locally, and additional forms of authentication such as mutual TLS as a secure transmission mechanism may be used to protect the progress tracking information remotely (i.e., on the server side).

[0132] Fig.11 Filtering of progress tracking information by daemon 440 according to some embodiments is shown. In some embodiments, daemon 440 is configured to filter progress tracking information received from progress application 1010 based on a set of activity contexts associated with one or more distributions assigned to students by one or more teachers. Daemon 440 can track a list of activity contexts 1170 based on attachments in one or more distributions currently assigned to students (or classes). In some embodiments, attachments in distributions with due dates that have passed can be closed (e.g., deactivated) by a teacher and removed from the list of activity contexts 1170. Daemon 440 is configured to filter progress tracking information received from progress application 1010 based on the list of activity contexts 1170.

[0133] For example, a first teacher may assign a first distribution to a specific student, the first distribution including activities associated with a first context of a first progress application 1010-1; and a second teacher may assign a second distribution to a specific student, the second distribution including activities associated with a second context of a second progress application 1010-2. The first context of the first progress application 1010-1 and the second context of the second progress application 1010-2 are considered active contexts. However, a student may use a third progress application 1010-3 that is not associated with any active context, and the daemon 440 may be configured to filter out (e.g., ignore) any progress tracking information 1140 received from the third progress application 1010-3 to avoid collecting any unnecessary progress tracking data. Similarly, the daemon 440 may also filter out any progress tracking information received from the first progress application 1010-1 and / or the second progress application 1010-2 that are associated with different inactive contexts. For example, an active context may define the structure of a Macbeth e-book, while an inactive context may define the structure of a Romeo and Juliet e-book. Any progress tracking information received when the Macbeth e-book is opened in the progress application 1010 will be processed by the daemon process 440, while progress tracking information received when the Romeo and Juliet e-book is opened in the progress application 1010 will be filtered out and ignored.

[0134] like Fig.11 As shown, first progress tracking information 1110 received from a first progress application 1010-1 and associated with a first context is processed by the daemon process 440, where the first context is included in the list of active contexts 1170. In some embodiments, the daemon process 440 stores the first progress tracking information 1110 as progress tracking information 1150-1 in the local database 450. The progress tracking information 1150-1 is uploaded to the progress area 465 in the remote database 460 whose scope is the student via a synchronization mechanism. Similarly, second progress tracking information 1120 received from a second progress application 1010-2 and associated with a second context is processed by the daemon process 440, where the second context is included in the list of active contexts 1170. The second progress tracking information 1120 is stored in the local database 450 as progress tracking information 1150-2. Likewise, the progress tracking information 1150-2 is uploaded to the progress area 465 in the remote database 460 whose scope is the student via a synchronization mechanism.

[0135] However, the third progress tracking information 1130 received from the second progress application 1010-2 and associated with the third context is ignored by the daemon process 440, wherein the third context is not included in the list of active contexts 1170. Similarly, the fourth progress tracking information 1140 received from the third progress application 1010-3 and associated with the fourth context is also ignored by the daemon process 440, wherein the fourth context is not included in the list of active contexts 1170.

[0136] The daemon 440 also creates metadata 1160 associated with the encrypted progress tracking information 1150. The metadata 1160 may include a reference to the encrypted progress tracking information 1150 in the remote database 460 and a context identifier of the context associated with the progress tracking information. In some embodiments, the metadata 1160 includes additional information that can be utilized by the progress pipeline 250, such as a class identifier, a distribution identifier corresponding to the context, an application identifier corresponding to the progress application 1010 that generated the progress tracking information 1150, or a user identifier associated with a user account logged into the client device 120 by the user. Therefore, the progress pipeline 250 does not process the actual progress tracking information that may contain PII. Instead, the progress pipeline 250 only processes the metadata 1160 associated with the progress tracking information, and the actual progress tracking information remains encrypted and stored in the personal progress area 465 of the remote database 460.

[0137] It should be appreciated that in other embodiments, the actual progress tracking information may be provided encrypted or unencrypted to the progress pipeline 250 instead of the metadata 1160. However, these embodiments may provide less security for the PII included in the progress tracking information.

[0138] It should be understood that the receipt of an active context implicitly authorizes the daemon 440 to track progress associated with that particular context. Once a context is removed from the active context list 1170, the implicit authorization is exited, so the daemon does not track progress associated with that context.

[0139] Fig.12 A progress pipeline 250 is shown according to some embodiments. The progress pipeline 250 is implemented on one or more server devices 110. In some embodiments, each component of the progress pipeline 250 is implemented on a different server device 110. In some cases, a particular component of the progress pipeline 250 is implemented on a cluster of server nodes, which may be referred to herein as a cluster.

[0140] like Fig.12As shown, the progress pipeline 250 receives progress tracking metadata 1202 from a daemon 440 included on one or more client devices 120 via the network 150. The progress pipeline 250 can be implemented as one or more services associated with a network address. Messages sent to the network address are processed by the corresponding service.

[0141] In some embodiments, the accessible service 1210 receives progress tracking metadata 1202 from one or more daemons 440. The progress tracking metadata 1202 includes information related to the progress tracking information 1150 of a particular student. In some embodiments, the progress tracking metadata 1202 includes a user identifier associated with a user account of the client application 210 and a context identifier of a particular context corresponding to the progress tracking information 1150.

[0142] In some embodiments, the accessible service 1210 is configured to check whether progress tracking is enabled for a particular user. An administrator may change a particular student's preferences in authorization via the school management service 240 to track the progress of a given student. The accessible service 1210 may receive notification of a change in the state of a given student's authorization preferences before the daemon 440 at a particular client device 120 receives the change. Therefore, even after the student has globally disabled progress tracking, the daemon 440 may continue to collect progress tracking information for a given student. Therefore, the accessible service 1210 performs a gating function of the progress tracking metadata received by the progress pipeline 250 based on a set of tags stored in the remote database 460.

[0143] In some embodiments, the list service is configured to periodically pull the set of authorization tags for each student in a particular school district using the school management service 240 and store the set of authorization tags in an authorization area 465 in the remote database 460, the scope of which is the organization. The accessible service 1210 can then query the set of authorization tags for each item of progress tracking metadata 1202 received using the user identifier included in the progress tracking metadata 1202.

[0144] In some embodiments, the accessible service 1210 calls the identity service 260 and requests a directory service identifier using the user identifier received in the progress tracking metadata 1202. When a user account is created, the directory service identifier may be registered as being associated with the user identifier. The directory service identifier is constant for the life of the user account and is only used within the server side of the client-server architecture 200, so that the client application 210 and / or the daemon 440 never receives the directory service identifier. Therefore, anyone snooping on the traffic between the daemon 440 and the progress pipeline 250 cannot obtain the directory service identifier to associate certain PII stored in one or more servers with the identifier of a particular user. The identity service 260 returns the directory service identifier to the accessible service 1210, which dereferences the user identifier included in the progress tracking metadata 1202 and replaces the user identifier with the directory service identifier. In some embodiments, the set of authorization tags corresponds to the directory service identifier, not the user identifier of the user account. Therefore, the user identifier is dereferenced before the accessible service 1210 performs the gating function. Once the accessible service 1210 has completed processing the progress tracking metadata 1202 , the progress tracking metadata 1202 is transmitted to the queue 1215 .

[0145] In other embodiments, an internal identifier may be utilized in place of the directory service identifier. Thus, the progress tracking metadata 1202 is tracked throughout the progress pipeline 250 using the internal identifier rather than the directory service identifier. This enables the progress pipeline 250 to sever all associations between progress tracking information and a particular user simply by deleting the association between the internal identifier and the directory service identifier.

[0146] In some embodiments, queue 1215 is a queue service implemented on server device 110. Queue 1215 may be implemented in the same server device 110 as accessible service 1210 or in a different server device 110. In some embodiments, queue 1215 is implemented as a distributed streaming service, such as Kafka distributed streaming platform. Queue 1215 enables access services 1210 and enrichment services 1220 to run asynchronously.

[0147] In some embodiments, the enrichment service 1220 is implemented on one or more server devices 110. The enrichment service 1220 is configured to receive the progress tracking metadata 1202 from the queue 1215 and enrich the progress tracking metadata 1202 with additional information. In some embodiments, the enrichment service 1220 requests roster data from the school management service 240 based on the directory service identifier included in the progress tracking metadata 1202. The roster data may include one or more class identifiers for any class in which the student is enrolled and a list of student identifiers for the students enrolled in each class. The school management service 240 may utilize the directory service identifier of the student instead of the user identifier provided by the daemon 440 within the original progress tracking metadata 1202. In other embodiments, the user identifier may be used to query the school management service 240 instead of an internal identifier.

[0148] The enrichment service 1220 can also retrieve all active distributions for a particular class from the corresponding area 465 in the remote database 460. The roster data and distributions are cross-referenced with the class identifier and directory service identifier included in the progress tracking metadata 1202 to append the additional information to the progress tracking metadata 1202 if it is not already included in the progress tracking metadata 1202. In some embodiments, the enrichment service 1220 ensures that the progress tracking metadata 1202 includes: the organization identifier, the class identifier, the distribution identifier, and the context identifier as well as a reference to the encrypted progress tracking information 1150.

[0149] In some embodiments, the progress tracking metadata 1202 can be associated with multiple class identifiers and / or multiple distribution identifiers. For example, if two different teachers from two different classes assign an activity to a particular student in two different distributions that reference the same context, then when the student completes an activity for one class, the student will also be considered to have completed the same activity for the other class. Once the enrichment service 1220 has enriched the progress tracking metadata 1202, the enrichment service 1220 transmits the enriched progress tracking metadata 1202 to the queue 1225.

[0150] In some embodiments, queue 1225 is similar to queue 1215. Queue 1225 can be implemented within the same server device 110 as enrichment service 1220 or a different server device 110.

[0151] In some embodiments, progress tracking metadata 1202 is populated from queue 1225 and stored in a distributed file system 1230. In some embodiments, distributed file system 1230 is implemented on a cluster of server nodes. Hadoop Distributed File System (HDFS). Each server node includes a set of inexpensive disk drives on which data can be stored. In some events, the distributed file system 1230 includes at least one log node configured to track changes to the progress tracking metadata 1202 stored in the distributed file system 1230. The log node protects the integrity of the progress tracking metadata 1202 in the event of a server node crash.

[0152] It should be understood that the progress pipeline 250 can be used by multiple organizations, even though the data for each organization is stored in a separate and distinct remote database 460 that is limited in scope to a particular organization. Thus, the distributed file system 1230 is storing a large amount of progress tracking metadata 1202 for one or more organizations. The aggregator service 1240 is designed to sort through all of the progress tracking metadata 1202 and organize the progress tracking metadata 1202 received by an organization during a tracking window. In some embodiments, the aggregator service 1240 is a computing service for processing large-scale data sets. For example, the aggregator service 1240 may be implemented as, but is not limited to, a server node implemented on a cluster of server nodes. The Spark service then processes the progress tracking metadata 1202 in one or more Spark jobs generated by the aggregator service 1240 .

[0153] In some embodiments, the tracking window may be, for example, a number of minutes or hours. For example, the aggregator service 1240 may sort the progress tracking metadata 1202 received within a ten minute window at the distributed file system 1230. In some embodiments, the aggregator service 1240 is configured to run a routine at the expiration of a timer set based on the tracking window. Once the routine is run, the timer is reset to wait for the expiration of the next tracking window.

[0154] In some embodiments, the aggregator service 1240 queries the log node of the distributed file system 1230 to collect all relevant information in the progress tracking metadata 1202 stored in the distributed file system 1230 during the tracking window. The log node tracks changes in the distributed file system 1230 and can return a list of all progress tracking metadata 1202 that have been stored in the distributed file system 1230 through the previous tracking window. The aggregator service 1240 is configured to pull the progress tracking metadata 1202 received during the tracking window and generate a data structure for each of the one or more organizations that submitted the progress tracking metadata 1202 to the progress pipeline 250 during the tracking window. The data structure may be referred to herein as a cube.

[0155] In some embodiments, the aggregator service 1240 generates separate and distinct cubes whose scope is a single organization. All of the progress tracking metadata 1202 corresponding to a particular organization identifier is sorted into the corresponding cube. The progress tracking metadata 1202 stored in a given cube can be sorted by class identifier, distribution identifier, context identifier, and student identifier (e.g., user identifier, directory service identifier, etc.).

[0156] In some embodiments, the cubes are stored in block storage 1250. In some embodiments, the block storage 1250 may be an HDD included in a server device 110 implementing the aggregator service 1240. In other embodiments, the block storage 1250 may be a virtual block storage device implemented on a set of one or more physical storage devices included in one or more server devices 110. In other embodiments, the block storage 1250 may be a distributed database service such as a server node cluster implemented on a server node. Cassandra Replacement. In other embodiments, block storage 1250 may be replaced by a distributed file system similar to distributed file system 1230 described above.

[0157] The aggregator service 1240 generates one or more cubes including the progress tracking metadata 1202 received during the tracking window of one or more corresponding organizations. The aggregator service 1240 adds a reference to each cube to a queue 1245. In some embodiments, the queue 1245 is similar to the queues 1215 and 1225, and enables the exitable service 1260 to operate asynchronously with the aggregator service 1240.

[0158] In some embodiments, the exitable service 1260 is configured to process each cube reference as it is populated from the queue 1245. In some embodiments, the exitable service 1260 is configured to read only the progress tracking metadata 1202 stored in a given cube in the block storage 1250 and write each progress tracking metadata 1202 entry to a specific area 465 in the remote database 460 that is scoped to a specific class, context, and optionally, student that is not based on the class identifier, context identifier, and / or directory service identifier / user identifier included in the progress tracking metadata 1202. Thus, the exitable service 1260 sorts the progress tracking metadata 1202 to a granularity smaller than a cube.

[0159] In other embodiments, the exit service 1260 may dereference the progress tracking metadata 1202 by replacing the directory service identity utilized by the previous service in the progress pipeline 250, and replace the directory service identifier with the progress identifier. The progress identifier may be associated with the directory service identifier in the identity service 260; however, the progress identifier may be disassociated from the directory service identifier to disconnect any connection between the progress tracking data 1150 and a particular user. In some embodiments, the progress identifier is discarded in response to the user's choice to exit progress tracking (e.g., globally disabling progress tracking). For example, an administrator for an organization may use the school management service 240 to disable progress tracking for a particular student, class, school, and / or entire school district. These changes may cause the identity service 260 to disassociate the progress identifier from the directory service identifiers of those students for which progress tracking has been disabled. Even though the progress tracking information may still exist in the remote database 460, once the association between the progress identifier and the directory service identifier has been broken, the progress tracking information may not be associated with a particular student.

[0160] Once the exitable service 1260 has completed processing the progress tracking metadata 1202, the progress tracking metadata 1202 is transmitted to the deposit service 1270. In some embodiments, the deposit service 1270 is implemented on at least one server device 110. The deposit service 1270 is configured to pull the encrypted progress tracking information 1150 reference through the progress tracking metadata 1202 entry and store the progress tracking information 1150 in the progress storage 1280. In some embodiments, the progress storage 1280 is a network-based storage service. The progress tracking information 1150 is stored in an area similar to the area 465, which is scoped by a specific class identifier, a context identifier, a progress identifier, and (optionally) a distribution identifier.

[0161] In some embodiments, the progress store 1280 is separate and distinct from the remote database 460 and is accessible only on the server side of the client-server architecture 200. Thus, the daemon 440 does not have direct visibility into the progress tracking information 1150 that has been archived by the progress pipeline 250. In other embodiments, the progress store 1280 may be implemented in a new area 465 in the remote database 460 and synchronized to the client device 120 using the reporting service 270.

[0162] Although not explicitly shown, the various services in the progress pipeline 250 may be configured to recycle specific progress tracking metadata 1202 processed by the service in the event that certain problems are encountered during processing. In some embodiments, a retry queue is associated with each service, and the progress tracking metadata 1202 may be pushed into the retry queue for processing at a later time. For example, a service such as the identity service 260 may be experiencing downtime that prevents the progress pipeline 250 from completing a particular operation. In such cases, the data processed by the service may be stored in the retry queue to attempt processing at a later time when the downtime service may be available. Alternatively, the service may be simply configured to add the progress tracking metadata 1202 back to the queue that interacts with the service's input. For example, the enrichment service 1220 may be configured to push the progress tracking metadata 1202 back to the queue 1215 for processing at a later point in time.

[0163] The reporting service 270 can then pull the progress tracking information 1204 from the progress store 1280 in response to a request from the client application 210 and / or the daemon process 440 to generate report data that is provided to the client application 210 and / or the daemon process 440 .

[0164] Fig.13 A client-server relationship between a reporting service 270 and a client application 210 and / or daemon 440 according to some embodiments is shown. The client application 210 and / or daemon 440 included in the client device 120 interacts with the reporting service 270 in the server device 110. After assigning a distribution to a class of students, the teacher may wish to track the students' progress in completing the distribution. More specifically, the GUI in the client application 210 can display a representation of progress tracking information associated with a particular distribution. Each of the attachments, submissions, and / or activities can be displayed along with information related to the completion progress of each of the students.

[0165] In some embodiments, the client application 210 receives input to display a representation of the distribution on the display 302 of the client device 120. In response to the input, the client application 210 requests a report from the reporting service 270. As used herein, a report may refer to a file or data structure that includes report data derived from the progress tracking information 1204 pulled from the progress storage 1280.

[0166] In some embodiments, the reporting service 270 receives a request for a report from the client application 210. The request may include a class identifier, a context identifier, a user identifier, and (optionally) a distribution identifier. The reporting service 270 may use the identity service 260 to find a progress identifier corresponding to the user identifier, and then query the progress store 1280 to retrieve progress tracking information 1204 corresponding to the class identifier, the context identifier, the progress identifier, and (optionally) the distribution identifier.

[0167] In addition, the request may specify a time frame associated with the request. For example, the request may specify whether the query should limit progress tracking information to time before the deadline of the distribution, time after the deadline of the distribution, or time up to and including the closing date of the distribution. As used herein, the closing date may refer to a time when a context attached to a distribution is deactivated, thereby preventing further progress tracking associated with the context after the closing date unless another distribution is assigned to the student that includes the context. Thus, the reporting service 270 generates a set of progress tracking information 1204 that corresponds to students in a particular class and for a particular context assigned in a particular distribution.

[0168] In some embodiments, daemon 440 summarizes the progress tracking information 1204 of class to calculate various statistics of class based on report data. For example, daemon 440 can calculate the total number of students in class, and the total number of students who have completed submission or activity. Daemon 440 can also use the timestamp associated with different progress tracking information 1204 to calculate the total time for each student to complete submission or activity (for example, by calculating the difference between the first timestamp and the last timestamp of all progress tracking information for a specific activity or submission). For another example, daemon 440 can calculate the score of each student based on the correct / incorrect response provided on the test or problem set. Daemon 440 can calculate the ratio of qualified score to unqualified score, the number of students with qualified score or the number of students with unqualified score and the ratio of the number of total students in class, the average score of class, the minimum score and the maximum score of class, the median score and standard distribution of score set, the score distribution mapped to letter grade (for example, the number of score A, the number of score B, etc.) and any other relevant statistics related to score and / or progress tracking information 1204.

[0169] In some embodiments, a student may attempt to complete a particular activity multiple times. For example, a student may take a test multiple times. In such embodiments, a request for a report may specify whether the report data should include progress tracking information 1204 for each attempt completed by the student or only the last attempt completed by the student. If the progress tracking information includes data for multiple attempts, the daemon 440 may be configured to calculate statistics related to the multiple attempts such as an average score, the highest score of all attempts, a ratio of passed attempts to failed attempts, etc.

[0170] In some embodiments, daemon 440 may also be configured to retrieve roster information from roster area 465 in remote database 460 in order to associate a user identifier associated with the progress tracking information with, for example, a student's name.

[0171] In other embodiments, the client application 210 is configured to perform the functions of aggregating the progress tracking information 1204 and / or calculating statistics related to the progress tracking information 1204 in the local database 450. The daemon 440 merely facilitates downloading the progress tracking information 1204 from the area 465 in the remote database 460 to the local database 450 to allow the client application 210 to access the progress tracking information 1204. The client application 210 is then configured to perform any necessary analysis using the progress tracking information 1204 in order to generate the values ​​to be populated in the fields of the GUI presented to the instructor.

[0172] Figures 14A to 14B 1 shows a GUI 1400 of a client application 210 according to some embodiments. The GUI 1400 can be used to present report data related to the assigned distribution to the teacher. The GUI 1400 can be presented on the display 302 of the client device 120. Fig.14A As shown, GUI 1400 is displayed on a tablet computer such as client device 120-2. GUI 1400 may include multiple elements including graphics, text, icons, shapes, input fields, display areas, etc. In some embodiments, GUI 1400 is displayed in response to the teacher selecting the element 312 for the distribution of the assignment in GUI 300.

[0173] GUI 1400 includes a first display area 1410 and a second display area 1420. The first display area 1410 presents information included in a distribution, such as the title of the distribution, the due date of the distribution, an indication of the class to which the distribution is assigned, and instructions included in the distribution assigned by the teacher. The second display area 1420 presents information related to any distribution and / or activities attached to the distribution by the teacher.

[0174] Each submission or activity attached to a distribution and presented in the second display area 1420 may also be presented with reporting data related to the submission or activity. The reporting data may be displayed within one or more elements 1422. For example, Fig.14A As shown, the activities associated with application two include: a first element 1422-1, which displays the ratio of passing scores to failing scores of students who have completed the activity; a second element 1422-2, which displays the average time for students to complete the activity; and a third element 1422-3, which displays the ratio of the number of students who have completed the activity to the total number of students in the class.

[0175] Additionally, an icon 1424 is presented adjacent to the submission or activity that enables the instructor to view more detailed information about the report data. Fig. 14B As shown, selecting icon 1424 may cause GUI 1400 to be updated to display detailed information in a second display area 1420 adjacent to the submission or activity. It should be understood that the second display area 1420 may be automatically adjusted to cover pixels in the display 302 that were previously covered by both the first display area 1410 and the second display area 1420. Of course, the extent of the second display area 1420 may remain the same as Fig.14A The same, or manually updated in response to a touch input gesture that repositions the first display area 1410 and / or the second display area 1420 up or down relative to the pixels of the display 302. For example, a swipe gesture can be used to scroll the first display area 1410 and / or the second display area 1420 up or down.

[0176] like Fig. 14B As shown, report data associated with each individual student enrolled in the class may be presented in GUI 1400. For example, detailed information entry 1426 includes the student's name, an indication of whether the student passed or failed the activity, (if completed) the time each student completed the activity in the third-party application, and an indication of whether the activity was completed. It should be understood that Fig. 14B The information shown is merely one example of the type of detailed information that may be presented in the GUI 1400. In other embodiments, the detailed information may include other types of statistical data or raw progress tracking information (e.g., a breakdown of each action tracked by the daemon 440 at the time the action was received by the daemon 440 and information related to the action). In other embodiments, the detailed information may include a graphical representation of the report data such as a graph or chart showing a student's progress over time, a link to a student submitting answers to a set of questions, a submission link or a record of activities performed by the student, etc.

[0177] In some embodiments, the detailed information may present a detailed breakdown of progress tracking information for sub-parts of a particular context. For example, a context may describe the structure of a set of questions assigned to a student. The progress tracking information may include information related to the answers provided by the student to each question in the set of questions. Therefore, even if the answers to the set of questions are considered to be the parent context, the sub-context of each question in the set of questions may track the answers to each individual question provided by the student. Therefore, the detailed information may enable the teacher to view the specific answers given for each question and whether the answers are correct or incorrect. GUI 1400 may enable such visual representations of progress tracking data to be easily viewed by the teacher.

[0178] In some embodiments, the client application 210 may output the results of the report data to a file or data structure to be archived for subsequent review by, for example, a teacher and / or administrator in determining a final grade for each student in the class.

[0179] Fig.15 1 is a flow diagram of a method 1500 for tracking student activity on a client device according to some embodiments. The method 1500 is performed by a client device 120. In some embodiments, the method 1500 may be implemented as logic configured to monitor activities associated with one or more applications. The logic may include instructions executed by a processor 410 of the client device 120 for monitoring the progress of students completing activities attached to a resource for distribution. In some embodiments, the method 1500 is implemented within logic implemented by a daemon process 440.

[0180] At 1502, progress tracking information is received from one or more applications. In some embodiments, the progress tracking information includes at least one of an application identifier corresponding to the application generating the progress tracking information, a context identifier corresponding to a particular context associated with the application, a timestamp indicating that the progress tracking information was generated, or information indicating an operation performed within the application and / or a result of the operation. In some embodiments, the progress tracking information is received by the daemon process within an API call generated by the application.

[0181] At 1504, the progress tracking information is filtered. In some embodiments, the progress tracking information is filtered based on determining whether progress tracking is enabled or disabled for each application in one or more applications installed on the client device. When progress tracking information is received from any application for which progress tracking is disabled, the progress tracking information is discarded, and when progress tracking information is received from any application for which progress tracking is enabled, the progress tracking information is processed. In other embodiments, a list of activity contexts associated with one or more applications is received, and the progress tracking information is compared with the list of activity contexts. For example, a context identifier included in the progress tracking information is compared with a plurality of context identifiers included in the list of activity contexts. When the progress tracking information corresponds to a context not included in the list of activity contexts, the progress tracking information is discarded, and when the progress tracking information corresponds to a context included in the list of activity contexts, the progress tracking information is processed.

[0182] At 1506, the progress tracking information is stored in a remote database accessible from the network. In some embodiments, the remote database is a network-based storage service that employs different areas to store different types of data limited to specific ranges. Disk-based encryption may be utilized to protect each area storing the progress tracking information, and authentication and message signing techniques may be used to limit access to the data to trusted servers. The progress tracking information may be stored in a personal area within the network-based storage service that is associated with a specific user identifier for a user account associated with a client application installed on the client device.

[0183] At 1508 , metadata associated with the progress tracking information is generated. The metadata may include a subset of the information in the progress tracking information, such as a user identifier and / or a context identifier, as well as information such as a reference to the progress tracking information stored in the remote database 460 .

[0184] At 1510, metadata of the progress tracking information is transmitted to a progress pipeline. In some embodiments, the progress pipeline enhances and aggregates progress tracking information received from multiple different client devices associated with multiple different students in one or more classes in one or more organizations. The progress pipeline may include multiple services implemented on multiple different server devices.

[0185] Fig.1616 is a flow diagram of a method 1600 for processing progress tracking information using one or more services available through a network according to some embodiments. The method 1600 is performed by the progress pipeline 250. In some embodiments, the method 1600 may be implemented as logic configured to process at least one of the progress tracking information or metadata corresponding to the progress tracking information. The logic may include instructions for processing the progress tracking information and / or the metadata executed by the processor 410 of the server device 110. In some embodiments, the method 1600 is implemented within logic implemented by one or more services, including the accessible service 1210, the enrichment service 1220, the distributed file system 1230, the aggregator service 1240, the exitable service 1260, and the deposit service 1270.

[0186] At 1602, metadata corresponding to progress tracking information is received from a plurality of client devices. In some embodiments, the metadata may include a reference to the progress tracking information stored in a remote database. The metadata may also include at least one of a class identifier, a user identifier, or a context identifier corresponding to the progress tracking information.

[0187] At 1604, the metadata is enriched with additional information. In some embodiments, the metadata supplemented by the additional data associates the progress tracking information with an organization identifier, a class identifier, a directory service identifier, a context identifier, and optionally a distribution identifier.

[0188] At 1606, a data structure is generated that includes a subset of metadata received by the progress pipeline during a tracking window for a particular organization. In some embodiments, the distributed file system utilizes at least one log node that enables all metadata received during the tracking window to be retrieved from the distributed file system. The service sorts the metadata into a different data structure corresponding to each of the one or more organizations that submitted metadata to the progress pipeline during the tracking window.

[0189] At 1608, the data structure is processed to generate sorted metadata based on the class identifier and / or the context identifier. The sorting may also be based on a directory service identifier or an internal identifier. The operation at 1608 may be performed for each data structure created for one or more organizations.

[0190] At 1610, progress tracking information corresponding to the sorted metadata is retrieved from a remote database. A reference included in the metadata can be used to request the progress tracking information from the remote database.

[0191] At 1612, the progress tracking information is stored in a memory accessible by the reporting service. In some embodiments, the progress tracking information is dereferenced from the directory service identifier or the internal identifier, and the progress identifier replaces the directory service identifier or the internal identifier in metadata associated with the progress tracking information. The progress identifier and the progress tracking information may be stored in a network-based storage service accessible to the reporting service. The client device may not be able to access the network-based storage service except indirectly through the reporting service.

[0192] Fig.17 A detailed view of an exemplary computing device 1700 that can be used to implement various apparatuses and / or methods described herein is shown according to some embodiments. In particular, the detailed view shows that a Figure 1 to Figure 1 4 and / or described herein. For example, server device 110, client device 120, or any other device including any network device and / or consumer electronics may include components of computing device 1700.

[0193] like Fig.17 As shown, the computing device 1700 may include a processor 1702 representing a microprocessor or controller for controlling the overall operation of the computing device 1700. The computing device 1700 may also include a user input device 1708 that allows a user of the computing device 1700 to interact with the computing device 1700. For example, the user input device 1708 may take a variety of forms such as buttons, keypads, dials, touch screens, audio input interfaces, visual / image capture input interfaces, input in the form of sensor data, etc. Further, the computing device 1700 may include a display 1710 (screen display) that can be controlled by the processor 1702 to present visual information to the user. The data bus 1716 may facilitate data transmission between at least the storage device 1740, the processor 1702, and the controller 1713. The controller 1713 can be used to interact with and control different devices through the device control bus 1714. The computing device 1700 may also include a network / bus interface 1711 coupled to the data link 1712. In the case of a wireless connection, the network / bus interface 1711 may include a wireless transceiver.

[0194] The computing device 1700 also includes a storage device 1740, which may include a single disk or multiple disks (e.g., a hard drive), and includes a storage management module that manages one or more partitions within the storage device 1740. In some embodiments, the storage device 1740 may include flash memory, semiconductor (solid-state) memory, etc. The computing device 1700 may also include a random access memory (RAM) 1720 and a read-only memory (ROM) 1722. The ROM 1722 may store programs, utilities, or processes to be executed in a non-volatile manner. The RAM 1720 may provide volatile data storage and store instructions related to the operation of the computing device 1700.

[0195] As mentioned above, one aspect of the present technology is to collect and use data from various sources to track the progress of students completing assignments. The disclosure contemplates that, in some instances, these collected data may include personal information data that uniquely identifies or can be used to contact or locate a specific person. Such personal information data may include demographic data, location-based data, phone numbers, email addresses, twitter IDs, home addresses, data or records (e.g., vital signs measurements, medication information, exercise information) related to the user's health or fitness level, date of birth, or any other identifying information or personal information.

[0196] The present disclosure recognizes that the use of such personal information data in the present technology can be used to benefit users. For example, personal information data can be used to improve the learning experience of individuals going to school. Therefore, the use of such personal information data enables teachers to adjust courses or provide individual attention to students' needs. In addition, the present disclosure also anticipates other uses of personal information data that benefit users. For example, health and fitness data can be used to provide insights into the user's overall health status, or can be used as positive feedback to individuals who use technology to pursue health goals.

[0197] This disclosure envisions that entities responsible for collecting, analyzing, disclosing, transmitting, storing or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities should implement and adhere to privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining the privacy and security of personal information data. Such policies should be easily accessible to users and should be updated as the collection and / or use of data changes. Personal information from users should be collected for legitimate and reasonable purposes of the entity and not shared or sold outside of these legitimate uses. In addition, such collection / sharing should be performed after receiving informed consent from the user. In addition, such entities should consider taking any necessary steps to defend and secure access to such personal information data and ensure that others who have access to personal information data comply with their privacy policies and processes. In addition, such entities may subject themselves to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. In addition, policies and practices should be adjusted to specific types of personal information data collected and / or accessed, and to applicable laws and standards including specific considerations of jurisdiction. For example, in the United States, the collection or access of certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA), while health data in other countries may be subject to other regulations and policies and should be handled accordingly. Therefore, different privacy practices should be maintained in each country for different types of personal data.

[0198] Regardless of the foregoing, the present disclosure also contemplates implementation schemes in which users selectively block the use or access of personal information data. That is, the present disclosure contemplates providing hardware elements and / or software elements to prevent or block access to such personal information data. For example, with respect to progress tracking services, the technology of the present invention may be configured to allow users to choose to "opt in" or "opt out" to participate in the collection of personal information data at any time during or after registration for the service. As another example, a user may choose not to provide progress tracking information for a particular third-party application. As another example, a user may choose to limit the scope of the data collected or completely prohibit the collection of progress tracking information. In addition to providing "opt-in" and "opt-out" options, the present disclosure contemplates providing notifications related to access or use of personal information. For example, a user may be notified that their personal information data will be accessed when downloading an application, and then the user may be reminded again just before the personal information data is accessed by the application.

[0199] In addition, it is an object of the present disclosure that personal information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use. Risks can be minimized by limiting data collection and deleting data once it is no longer needed. In addition, and when applicable, including in certain health-related applications, data de-identification can be used to protect the privacy of users. De-identification can be facilitated by removing specific identifiers (e.g., date of birth, etc.), controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than at the address level), controlling how data is stored (e.g., aggregating data between users), and / or other methods when appropriate.

[0200] Thus, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that various embodiments may also be implemented without access to such personal information data. That is, various embodiments of the present technology will not fail to function properly due to the lack of all or a portion of such personal information data. For example, progress tracking may be implemented based on non-personal information data or an absolute minimum amount of personal information (such as other non-personal information or publicly available information available to the progress tracking pipeline).

[0201] The various aspects, embodiments, specific implementations or features of the embodiments may be used individually or in any combination. The various aspects of the embodiments may be implemented by software, hardware, or a combination of hardware and software. The embodiments may also be implemented as computer readable code on a non-transient computer readable medium. A non-transient computer readable medium is any data storage device that can store data, which can then be read by a computer system. Examples of non-transient computer readable media include read-only memory, random access memory, CD-ROM, HDD, DVD, magnetic tape, and optical data storage devices. Non-transient computer readable media may also be distributed on a network coupled computer system so that the computer readable code is stored and executed in a distributed manner.

[0202] For the purpose of illustration, the foregoing description uses specific nomenclature to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that the embodiments can be practiced without specific details. Therefore, the foregoing description of specific embodiments is presented for the purpose of illustration and description. The foregoing description is not intended to be exhaustive or to limit the embodiments described to the precise form disclosed. It will be apparent to those of ordinary skill in the art that, in view of the above teachings, many modifications and variations are feasible.

Claims

1. A method for processing progress tracking information using one or more services available via a network, the method comprising: receiving metadata corresponding to progress tracking information from a plurality of client devices; generating a data structure comprising a subset of the metadata received during a tracking window for a particular organization identified by an organization identifier; processing the data structure to generate sorted metadata based on the class identifier and the context identifier; as well as The progress tracking information corresponding to the sorted metadata is stored in a memory accessible to a service.

2. The method according to claim 1, further comprising: The metadata is enriched to include additional information.

3. The method according to claim 2, wherein: The additional information includes at least one of an organization identifier, a directory service identifier, or a distribution identifier.

4. The method according to claim 1, wherein: The one or more services include at least one of an accessible service, an enriched service, a distributed file system, an aggregator service, an exitable service, and a depository service.

5. The method according to claim 1, wherein: Each of the plurality of client devices collects progress tracking information by: A respective context is received from each of the one or more applications on the client device, the respective context defining a respective structure of progress tracking information to be provided by the application related to student activities performed within the application.

6. The method according to claim 5, wherein: Each of the plurality of client devices collects progress tracking information by: Respective progress tracking information is received from at least one application of the one or more applications, wherein the respective progress tracking information is provided by the at least one application according to the respective context of the at least one application.

7. A system for tracking the progress of a student assigned one or more digital distributions via a client application, the system comprising: One or more server devices connected to the network and configured to implement a service for tracking a student's progress in completing the one or more digital distributions, the service comprising: a distribution service that enables the one or more digital distributions to be created and linked to a context associated with one or more applications installed on at least one client device, wherein each of the one or more applications implements at least a portion of a software framework, and A progress pipeline includes a plurality of services configured to process progress tracking information generated by the one or more applications installed on the at least one client device.

8. The system according to claim 7, wherein: The progress pipeline includes a first service, wherein the first service is configured to: receiving metadata corresponding to progress tracking information; dereferencing the user identifier by replacing the user identifier included in the metadata with a directory service identifier or an internal identifier; determining whether progress tracking is enabled or disabled for one of the user identifier, the directory service identifier, or the internal identifier; as well as The metadata is filtered based on the determination.

9. The system according to claim 8, wherein: The progress pipeline includes a second service, wherein the second service is configured to: The metadata is enriched with at least one of an organization identifier, the directory service identifier, the internal identifier, or a distribution identifier.

10. The system according to claim 8, wherein: The progress pipeline includes a second service, wherein the second service is configured to: retrieving a subset of metadata corresponding to the tracking window from a distributed file system including at least one log node; generating a data structure including the subset of metadata associated with a specific organization identifier included in the subset of metadata; storing the data structure in a storage service; as well as A reference corresponding to the data structure is pushed into the queue.

11. The system according to claim 8, wherein: The progress pipeline includes a second service, wherein the second service is configured to: The data structure is processed to generate sorted metadata based on at least one of a class identifier, a distribution identifier, a context identifier, the user identifier, the directory service identifier, or the internal identifier.

12. The system according to claim 8, wherein: The progress pipeline includes a second service, wherein the second service is configured to: associating the progress tracking information with a progress identifier associated with one of the user identifier, the directory service identifier, or the internal identifier; as well as The progress tracking information and the progress identifier are stored in a network-based storage service.

13. The system according to claim 7, wherein: Each client device includes a daemon process configured to synchronize data stored in a local database on the client device to a remote database so that the data is accessible to a second client device.

14. At least one server device for tracking the progress of students assigned one or more digital distributions via a client application, the at least one server device being configured to implement a service for tracking the progress of students in completing the one or more digital distributions, the service comprising: a distribution service that enables the one or more electronic distributions to be created and linked to a context associated with one or more applications installed on at least one client device, wherein each of the one or more applications implements at least a portion of a software framework; as well as A progress pipeline includes a plurality of services configured to process progress tracking information generated by the one or more applications installed on the at least one client device.

15. At least one server device according to claim 14, wherein: The progress pipeline includes a first service, wherein the first service is configured to: receiving metadata corresponding to progress tracking information; dereferencing the user identifier by replacing the user identifier included in the metadata with a directory service identifier or an internal identifier; determining whether progress tracking is enabled or disabled for one of the user identifier, the directory service identifier, or the internal identifier; as well as The metadata is filtered based on the determination.

16. At least one server device according to claim 15, wherein: The progress pipeline includes a second service, wherein the second service is configured to: The metadata is enriched with at least one of an organization identifier, the directory service identifier, the internal identifier, or a distribution identifier.

17. The at least one server device according to claim 15, wherein: The progress pipeline includes a second service, wherein the second service is configured to: retrieving a subset of metadata corresponding to the tracking window from a distributed file system including at least one log node; generating a data structure including the subset of metadata associated with a specific organization identifier included in the subset of metadata; storing the data structure in a storage service; as well as A reference corresponding to the data structure is pushed into the queue.

18. The at least one server device according to claim 15, wherein: The progress pipeline includes a second service, wherein the second service is configured to: The data structure is processed to generate sorted metadata based on at least one of a class identifier, a distribution identifier, a context identifier, the user identifier, the directory service identifier, or the internal identifier.

19. The at least one server device according to claim 15, wherein: The progress pipeline includes a second service, wherein the second service is configured to: associating the progress tracking information with a progress identifier associated with one of the user identifier, the directory service identifier, or the internal identifier; as well as The progress tracking information and the progress identifier are stored in a network-based storage service.

20. The at least one server device of claim 14, wherein: Each client device includes a daemon process configured to synchronize data stored in a local database on the client device to a remote database so that the data is accessible to a second client device.

Images