US20020198994A1 - Method and system for enabling and controlling communication topology, access to resources, and document flow in a distributed networking environment - Google Patents

Abstract

Described are a system and method for use by a computing device to transmit information over a communication medium. The computing device communicates over the medium according to a protocol stack having a plurality of protocol layers. Information having an identifier is received at a first protocol layer from a higher protocol layer in the protocol stack. The computing device determines whether to present the information to the network communication medium based on at least one term of a contract associated with the identifier. Upon determining to present the information to the communication medium, the computing device incorporates the identifier in the information before placing the information on the network communication medium.

Description

RELATED APPLICATION
• This application claims the benefit of the filing date of co-pending U.S. Provisional Application Serial No. 60/291,200, filed May 15, 2001, entitled “Method for Controlling Classroom Communications Over a Wireless Network”, the entirety of which provisional application is incorporated by reference herein.[0001]
FIELD OF THE INVENTION
• The invention relates generally to networks of computing devices. More specifically, the invention relates to facilitating communications among individuals, groups, and leaders using networked computing devices.[0002]
BACKGROUND
• Most students now have occasional, supplementary Internet access at school, which has been sufficient to enable the initial growth of a large, diverse market of hardware, services, and content. However, within the tethered desktop or laptop paradigm, school access is unlikely to drop from the present 6:1 student-to-computer ratio to an ideal 1:1 ratio because of cost, installation, and portability issues. Hence, students will need to share a limited number of computers while at school and suffer from a lack of continuity between their computing environment at school and what they have at home (more than 60% of school-aged children now have access to a computer at home). This hardware shortage restricts individual access to school computing to less than 1 hour a week, on average, thus limiting students' opportunities to gain the highly-touted benefits of educational computing.[0003]
• The market is rapidly developing affordable, powerful handheld computing devices and fast, easily installed, low-power wireless networks that may allow schools to overcome these limitations. In particular, mobile ad hoc networks (MANETs) are becoming readily available and highly attractive to schools for their low cost, ease of installation, and minimal maintenance. MANETs have a superset of the 802.11 capabilities that are available today: such networks support multicast, allow direct peer-to-peer communications without going through a central access point, support ad hoc networking, and provide an API (application programming interface) for controlling some key performance parameters.[0004]
• A critical barrier to the acceptance of handheld (and wireless) devices in educational settings is the perception that the devices will enable disruptive “message passing” among students or cheating on tests. To overcome this barrier, teachers and proctors need a way of monitoring and blocking inappropriate student communication or computation. More generally, teachers need ways both of enabling particular kinds and patterns of communication and disabling others. In addition, because students can move around, and can work together in settings both inside different schoolrooms and outside of school altogether, controlled patterns of communication should be enabled without requiring a central communication hub, filter, or monitor. (Such a hub presents a single point of failure.) Further, it should be easy for teachers to designate particular roles for particular students without becoming network system administrators. Finally, it would be convenient if the process of choosing a particular destination for content was automated or simplified, so that students need not navigate complex choices to send or receive planned information flows.[0005]
SUMMARY OF THE INVENTION
• One objective of this invention is to provide a framework that helps a teacher or other leader manage the use of computing (or communication) devices by their students in a classroom.[0006]
• In one aspect, the invention features a method for use by a computing device to transmit information to at least one other computing device over a network communication medium according to a protocol stack having a plurality of protocol layers. The information is received at the particular protocol layer from a higher protocol layer in the protocol stack. At this particular protocol layer the computing device determines whether to transmit information over the network communication medium based on at least one term of a contract associated with the information. Upon determining to present the information to the network communication medium, the information is forwarded to a lower protocol layer in the protocol stack for transmission over the communication medium. An identifier is associated with each contract and becomes incorporated in information associated with that contract before that information is transmitted over the network communication medium. The information may be encrypted before being transmitted over the network communication medium.[0007]
• In another aspect, the invention features a method for use by a computing device to receive information from at least one other computing device over a network communication. The computing device identifies at a particular protocol layer of a protocol stack a contract associated with information received over the network communication medium. The computing device receiving the information over the network communication medium extracts the identifier from the information, and after determining that the computing device has a copy of the contract, determines whether to send the information to a higher protocol layer of the protocol stack based on one or more terms of the contract. The information may need decrypting before being sent to the particular protocol layer.[0008]
• Contracts can be transmitted and received to and from other computing devices over the network communication medium. Communication of the contract can occur using one of IR (infrared) beaming, RF (radio frequency) communication, and wired communication. Generally, the contract can pass over a secure communication channel. Computing devices and network resources store the contracts, and may store a plurality of different contracts. In general, stored contracts cannot be modified by any program other than a program that handles the contract protocol layer.[0009]
• Each contract specifies one or more terms that the information associated with the contract must satisfy in order to be transmitted over the network communication medium. Such terms can determine which actions, if any, can be performed on the information by a computing device receiving the information. Each term includes a parameter such as a temporal parameter, an information-type parameter, an information-length parameter, and an information-content parameter.[0010]
• If the terms of a contract allow, the user of a computing device that receives the contract can transmit a copy of the contract to the user of another computing device. The contract may be provided to a plurality of computing devices. In one exemplary configuration, the contract permits one of the computing devices having the contract to transmit information associated with the contract and another of the computing devices having the contract to receive information associated with the contract. In another exemplary configuration, the contract permits each computing device having the contract to transmit and to receive information associated with the contract.[0011]
• In one embodiment, a computing device enters a secure mode of operation in response to information received over the network communication medium. The computing device can be placed in the secure mode of operation for a predefined duration. The computing device can issue a reply indicating that the first computing device has entered the secure mode of operation. The reply includes any one or a combination of (i) a certificate of authenticity, (ii) a certificate of integrity, (iii) a version number, and (iv) a characteristic of the computing device. An indicator on the first computing device is activated, verifiably showing that the first computing device is operating in the secure mode of operation.[0012]
• The computing device can receive the information over the network communication medium from a security station. In one embodiment, the security station is a wireless access point in the control of a server system. In another embodiment, the security station can include an infrared beaming port. The security station can be located where a user of the first computing device entering a restricted zone necessarily passes near the security station.[0013]
• The indicator can be any one or a combination of a sticker affixed to a visible surface of the computing device after the computing device is operating in the secure mode of operation, a detectable output produced by the computing device, or the capability of the computing device to respond correctly to a challenge. The detectable output can be any one or a combination of an illuminated LED (light emitting diode), an emitted sound, or a wireless transmission that indicates the computing device is operating in the secure mode.[0014]
• A computing device that is operating in the secure mode is capable of correctly responding to a predefined challenge. The challenge may be received over a wireless network medium (IR or RF), wired network, or at the computing device. In one embodiment, the challenge includes providing a predefined input to the first computing device. In another embodiment, the challenge includes pressing one or more particular keys on a keyboard of the first computing device. The computing device computes a response that demonstrates the authenticity and integrity of the first computing device.[0015]
• Entering the secure mode of operation includes prohibiting the first computing device from at least one of (i) communicating over a particular physical link, (ii) launching an application program, (iii) storing data in memory, (iv) reading data from memory, (v) installing software, (vi) communicating with hardware, (vii) accessing a particular system library, (viii) performing a start-up type of action, and (ix) placing a restriction on a specific application program. Another security-related feature is maintaining a session on the first computing device across a start-up type of event.[0016]
• In yet another aspect, the invention features a method for providing a a computing device with a capability to perform an interaction with a resource in a wireless network. A first message is transmitted from a first computing device to a second computing device to initiate a capability exchange. A response to the first message is received at the first computing device indicating a type of interaction that is supported by the second computing device. A second message including a contract corresponding to the type of interaction is transmitted from the first computing device to the second computing device to provide the second computing device with the capability to perform the interaction.[0017]
• In some embodiments, transmission of the first message occurs when a predefined key of the first computing device is pressed, through an infrared transceiver of the first computing device, and includes transmitting type information representing content in the first message. The transmission can be a point-to-point transmission directed to a specific transceiver on the second computing device that is dedicated to respond to the first message. The information that corresponds to the interaction type can also be transmitted to a resource in the network to enable interaction between the second computing device and the resource.[0018]
• In yet another aspect, the invention features an article of manufacture having computer-readable program means embodied thereon for communicating over a network communication medium. The article of manufacture comprises computer-readable program means for determining at a particular protocol layer of a protocol stack that a message is associated with a contract, and computer-readable program means for accessing the contract at the particular protocol layer to determine from at least one term of the contract whether to forward the message from the particular protocol layer.[0019]
• In yet another aspect, the invention features a method of controlling access to an electronic resource. The electronic resource is given a contract that has an identifier. The contract specifies one or more conditions that determine the rules of communication with the electronic resource. When the electronic resource receives a communication, the electronic resource determines whether that communication has the identifier of the contract. If so, the electronic resource processes the communication. Otherwise, the communication is filtered out. Further, if that communication satisfies each condition specified by the contract, the electronic resource processes the communication; otherwise such communication is filtered out. The identifier of the contract is given to a computing device for inclusion in communications sent by the computing device to the electronic resource to enable the computing device to use the electronic resource.[0020]
BRIEF DESCRIPTION OF THE DRAWINGS
• The invention is pointed out with particularity in the appended claims. The objectives advantages of the invention described above, as well as further objectives and advantages of the invention, may be better understood by reference to the following description taken in conjunction with the accompanying drawings, in which:[0021]
• FIG. 1 is a block diagram of an embodiment of a network embodying the principles of the invention;[0022]
• FIG. 1A is a diagram of an embodiment of a protocol stack used by computing devices in the network to communicate with each other and with network resources;[0023]
• FIG. 2 is a flow diagram of an embodiment of a process by which one computing device transmits a “share pair” to a second computing device, to give the second computing device a specific capability;[0024]
• FIG. 2A is a flow diagram showing an embodiment of a process for operating a computing device in a secure mode for engaging in security-sensitive activities, such as administering and taking a test;[0025]
• FIGS.[0026]3A-3D are conceptual diagrams of four exemplary share-pair configurations;
• FIG. 4 is a diagram illustrating exemplary capabilities given to computing devices through the distribution of at least one of the share-pair configurations shown in FIGS.[0027]3A-3D;
• FIGS.[0028]5A-5C are conceptual diagrams illustrating a grammar that can describe different classroom activities and topologies;
• FIG. 6 is a flow diagram of a process by which the binding of metadata-based data to share-pairs controls document flow through the network;[0029]
• FIGS.[0030]7A-7B are diagrams of an embodiment of document forwarding performed by computing devices in the network;
• FIG. 8 is a block diagram of components for implementing a packet transmission protocol of the invention;[0031]
• FIG. 9 shows an embodiment of a process by which a computing device (i.e., node) determines a local connectivity number;[0032]
• FIGS.[0033]10A-10E are conceptual diagrams illustrating examples of network configurations and examples for determining a local connectivity number in the network configurations;
• FIG. 11 is a flow diagram of an embodiment of a process by which a node determines whether to reply to a query; and[0034]
• FIGS.[0035]12A-12B are flow diagrams of an embodiment of a process by which a node determines whether to repeat a received packet.
DETAILED DESCRIPTION
• To facilitate an understanding of the following description, we describe a classroom activity or game that illustrates generally the principles of the invention.[0036]
• Consider that a teacher has a set of colored envelopes and a set of colored inboxes. The teacher distributes these envelopes and inboxes as follows:[0037]
• on student A's desk (referred to as Suzie): Red envelopes; a Blue inbox; Green envelopes; and a Green inbox;[0038]
• on student B's desk (referred to as John): a Blue inbox; Green envelopes; and a Green inbox;[0039]
• on the Teacher's desk: Blue envelopes; and[0040]
• on the Printer desk: a Red inbox.[0041]
• All communications in the classroom follow these rules:[0042]
• 1. Only someone with an envelope can send information. They send a message by putting the message into an envelope, sealing it, and throwing it into the air.[0043]
• 2. Once in the air, the envelope is duplicated and delivered to every single desktop (as described below, this mechanism is embodied as digital shared medium communication, in which duplication to every destination is the normal case).[0044]
• 3. Every participant in the classroom has agreed that if they recieve an envelope for which they do not have the same colored inbox, they will immediately discard it.[0045]
• Now, consider that the teacher puts a worksheet into a blue envelope and throws it in the air. Suzie, John, and the printer each get the blue envelope; the printer, however, lacking a blue inbox, discards it. Suzie and John open the blue envelope and read the message (i.e., the worksheet).[0046]
• The message says “Make two lists. Step One: On one list, put five characteristics of mammals. On the other list, write five characteristics of reptiles. Put your lists in a green envelope. Step Two: If you have a red envelope, collect all the lists, including your own. Make an aggregated set of three lists “agreed mammal characteristic”,“agreed reptile characteristic,” “not sure.” Print your aggregation by putting it in a red envelope.[0047]
• Suzie makes her three lists, puts them in a green envelope, and throws it in the air. John does the same. The teacher, and the printer discard both green envelopes that they recieve, but John opens Suzie's and grins “we agreed a bunch” Suzie says, “yup, but I don't agree that all reptiles live on land.[0048]
• She makes a new message with three lists, places the message in a red envelope and throws the red envelope in the air. The printer, having a red inbox, opens the red envelope and prints the list. The teacher and John receive the red envelope too, but lacking a red inbox throw the red envelope away.[0049]
• The scheme of colored envelopes and colored inboxes conceptually illustrate a principle of the invention referred to as “share pairs.” Each color represents a kind of communication. The envelopes and inboxes with the same color form a share pair that together regulates information exchange: only students with an envelope may transmit and only students with a matching inbox may receive. An envelope represents a contract between the teacher and a first student: it gives the first student the capability to transmit a message with the given identifying color. An inbox represents another contract between the teacher and a second student: it gives the second student the capability to receive a message with the given identifying color. This pair of contracts thus contractually regulates sharing of information among the first and student students, hence the term “share pair.” By creating share pairs and handing out each half to different student desks, the teacher structures the possible communications, communication topologies, access to resources, and document flow.[0050]
• Moreover, note that two kinds of communication appear in the game. More specifically, the teacher uses a first type, directed one-to-one communication, to regulate a second type, shared-medium communications. When the teacher hands an envelope or inbox to a student, she is engaged in the first type, that is, directed one-to-one communiction. Afterwards, when the students use envelopes and inboxes to communicate, they use the second type, shared medium communication (i.e., every envelope is broadcast to every receiver). Accordingly, the share pairs regulate shared medium (e.g. wireless) communication.[0051]
• Further note that the principles of share pairs operate without a centralized message router; once students have envelopes or inboxes, messages do not pass through a single controlling filter. Also, by employing different ways of distributing envelopes and inboxes, the teacher can orchestrate a wide variety of possible communication flows, but no single participant ever needs to know all the flow rules. Each participant has only those rules that pertain to information that the particular participant may send or recieve. Consequently, the information to control information flow is decentralized, and there is no single point of failure in the system.[0052]
• An issue that may arise with the share-pair scheme as described above is that anyone who has an envelope can put anything they like in that envelope. Consequently, Suzie and John can exchange, for example, their favorite baseball trading cards by using green envelopes, a practice that the teacher does not abide in her classroom. Thus, the teacher seeks control over what content is copied over the shared medium.[0053]
• Accordingly, from now on, messages are no longer be wantonly thrown into the air. Instead the teacher distributes outboxes with the same color to each student that has an envelope. The outbox enforces contract terms which regulate transmisions. These terms state rules that the envelope and its contents must obey in order to pass through. These rules govern the size, type, and other properties of the envelope and its contents. Only envelopes that satisfy the rules may now enter the shared communication medium. (Similar contracts govern inboxes.) Now the teacher can control not only topologies of communication, but also what sorts of content can flow along each possible route.[0054]
• In one variation of the game, there are no separate inboxes and outboxes. Instead, the contract can govern whether a box can be used for input, output, or both. A “share pair” is a matching set of contracts, with a given color for the whole set. From this set, the teacher can choose specific contracts to attach to each box she hands out, and thereby create restricted patterns of envelope transfer among all boxes with the same color. Again the teacher need not maintain any centralized list of all the contracts; the information is decentralized and not sensitive to any single point of failure.[0055]
• When different boxes of the same color have asymmetrical but matching contracts (e.g. they both admit the same types of content, but one contract allows only transmitting and the other contract allows only receiving), the contracts together enable particular direction of flow of a certain color of envelopes. By combining a small set of basic contractual types, the teacher can create a wide diversity of desirable information flow models, including “distributing” a worksheet to everyone in class, “collecting” homework from each individual, “sharing” information among designated teams, and “accessing” designated resources.[0056]
• Content Routing[0057]
• Another issue that may arise is that students may have difficulty remembering what kind of thing (i.e., content) goes in what color envelope. To mitigate this complexity, each participant has an automated “envelope stuffer,” which can accept any kind of message, that determines for the participant what color envelope to use.[0058]
• Upon receiving a message for transmission, the envelope stuffer checks every available contract, to see if any can potentially transmit this message. If only one contract can transmit the message, stuffer selects the envelope matching that contract, and the envelope is placed in the outbox. If more than one contract can transmit the message, the user is presented with a choice among the possibilities.[0059]
• The teacher may now put colored stickers on response cards that she gives to the students. Now when the teacher sends the worksheet, it includes two cards. One card has space for two lists, and the other card has space for three lists. The two-list card has a green sticker, and the three-list card has a red sticker. The contracts include terms that allow a card with a given color of sticker to be transmitted. Consequently, the students can just put their completed cards in the stuffer. The stuffer then automatically selects a red or green envelope selected for the cards.[0060]
• Hip Hop Multicast[0061]
• As it turns out, consider that broadcasting every message so as to reach every desk consumes too much energy. A variation of the game solves this problem. Instead of throwing an envelope the air so as to reach every desk in a classroom, each participant lightly tosses the envelope such that copies only land on desks within a short (e.g., six-foot) radius. A new rule is added to the system; every desk that receives an envelope makes a copy, and then lightly throws that copy back into the air. Eventually, every desk receives at least one copy of the envelope, provided the desks are reasonably densely packed.[0062]
• This can present a problem: the air is constantly full of repeated throwings of the first envelope, and so no other envelopes can pass through. Another rule addresses this problem by introducing a “count for a while, then decide” methodology (hereafter referred to as “Hip Hop multicast”). Each desk waits a while, and while waiting, counts how many repetitions of a message that it receives. If the wait time ends before the desk's count reaches a threshold, the desk resends the message. Due to the wait and count step, the first message is repeated only a finite number of times, but enough times to assuredly reach every desk.[0063]
• Data Migration[0064]
• Consider that the printer jams just after opening Suzie's red envelope, and cannot complete her print job. Worse, Suzie has left class, and so the printer cannot ask her to resend the file to be printed again.[0065]
• To address the problem of “missed communications”, a description of the contents can be attached to each envelope, e.g. a file name. Further, recall that according to the Message Hop methodology a student keeps every envelope for a while, to decide whether to retransmit that envelope. As a variation, the student retains all envelopes that are received in a cache (at least until the cache fills up). As messages pass through the air, the cache accumulates colored envelopes with associated file names. The cache can include colors of envelopes for which the desk has no inbox or outbox.[0066]
• Further, inboxes are permitted to query for pending transfers from all the desks that share its airspace. Hence, the printer can ask “any red envelopes for me?” Each desk searches its cache, and returns a list describing the red envelopes that it has available. The printer can select the red envelope it wishes to receive, and send another query “please send the red envelope entitled ‘Suzie's lists.pdf’ to me.” Each desk searches its cache, and returns that envelope if it has it.[0067]
• This capability allows the system to solve “missed communication” problems by finding copies of recent communications in cache. Further, the capability solves “late comer” problems by allowing a participant that was “offline” (i.e., not in the classroom) during a recent wireless transmission query to see what was sent recently. Indeed, it is possible that Suzie could get a copy of the worksheet in class, but John might be at home sick. When they later meet at a café, John could get all the recent green and blue items from Suzie.[0068]
• FIG. 1 shows embodiments of a[0069]network2 constructed in accordance with the principles of the invention. In one of the embodiments, thenetwork2 includes a plurality ofcomputing devices12,12′, and12″ (generally12) in communication with each other over a wireless medium to form awireless communication network6.
• In general, the invention is useful in environments where one or more leaders, teachers, or instructors instruct or address individuals and groups of individuals. In one embodiment, the[0070]network2 is implemented within an educational environment, such as a classroom having at least one teacher and a plurality of students. In this embodiment, each teacher and student has a handheldportable computing device12. Class participants are connected by thewireless network6. For illustrating the invention, consider that the teacher operates the computing device12 (hereafter, teacher device12), and the students operate one of thecomputing devices12′,12″ (hereafter, individually,student device12′ andstudent device12″, and generallystudent device12′). Hereafter, references to acomputing device12 refer generally to computing devices, which can be a teacher device,12, astudent device12′, or both.
• In a classroom having a teacher and a plurality of students, a variety of interaction or activity topologies arise among such classroom participants. For example, the teacher can place students into project groups with an assigned group leader where information is shared among group members. As another example, the teacher can require the students to work individually on an assignment, test, or quiz. The overall pattern of interactions among the[0071]student devices12′ and theteacher device12 in a classroom (and the corresponding links between the classroom participants) can become complex. Each set of interactions amongstudent devices12′ and theteacher device12 and the corresponding links defines an interaction topology.
• Within these complex topologies, the teacher wants to be able to control the message or document flow among the students. For example, the teacher would not want students to be able to work together in groups for an assignment that requires individual effort, such as a test. Yet, there are moments in the classroom when students should be able to share documents, such as when the students are working together on a project.[0072]
• Computing Devices[0073]
• Typically, the[0074]computing devices12 are battery-operated, portable devices capable of wireless communication (point-to-point infrared (IR), shared medium radio frequency (RF), or both). Examples ofsuch computing devices12 include but are not limited to personal digital assistants (PDA), tablet-based and laptop computers, calculators, mobile phones, handheld gaming devices, and picoradios.
• In another of the embodiments, the[0075]network2 further includes electronic resources such as aprinter14, aprojection display14′, and arobot14″ (generally14) connected to awireless access point16. In this embodiment, thewireless access point16 is a part of thewireless network6. The electronic resources14 (also referred to as network resources) shown are simply exemplary; other types of electronic resources, such as, but not limited to, scanners, fax machines, and data collection devices, can be in thenetwork2 embodying the invention. Theelectronic resources14 are part of a wired data communication network10. In some embodiments, one or more of thecomputing devices12 can be part of the wired network10 rather than or in addition to being part of thewireless network6. The wired network10 can be a WAN (wide area network), LAN (local area network), or client/server network. The wired andwireless networks6,10 are connected to each other through thewireless access point16. Thewireless access point16 serves as a shared RF wireless transceiver for theelectronic resources14 on the wired network10. In some embodiments, one or more of theelectronic resources14 is local to thecomputing devices12 and have an RF transceiver. In such embodiments, theelectronic resources14 can communicate with thecomputing devices12 directly through the RF transceiver (i.e., thewireless access point16 is not needed for such RF communication). Somecomputing devices12 can require a connection to an AC outlet or not be portable, such as desktop computers.
• Point to Point Transcievers[0076]
• [0077]Computing devices12 can have one or more “point-to-point” short-rangewireless communication transceivers20,20′ (generally20). Examples of thesetransceivers20 include infrared (IR) and very short range (e.g. Personal Area Network or PAN) radio frequency (RF) transceivers (sometimes referred to in the art as “cable replacements”). (In FIG. 1, IR transceivers are designated20 and PAN RF transceivers as20′.)IR transceivers20 include an IR emitter and IR sensor for point-to-point exchange of information with a peer device (a process called “beaming”).RF transceivers20′ include an antenna for broadcasting and receiving information to and from peer devices within broadcast range and tuned in to a predetermined frequency spectrum (e.g., 900 MHz and 2.4 Ghz).
• Multiple, Spatially Distiguished Point to Point Transcievers[0078]
• In general, the physical distribution of short-range “cable replacement” wireless connections can be used to give a user choice among differentiated capabilities of an[0079]overall network system2. More specifically, in some embodiments the computing devices12 (and electronic resources14) have more than one point to pointtransceiver20. In such embodiments, thetransceivers20 are spaced sufficiently far from each other so that eachtransceiver20 can communicate independently of theother transceivers20. Eachtransceiver20 can be integral to the body of thedevice12 or attached to thedevice12 by short wires or other network cabling means such as ethernet cabling. Forcomputing devices12 andelectronic resources14 withmultiple transceivers20, short wires can increase the spatial separation between thetransceivers20.
• A unique label[0080]22 (e.g., human readable text, color-coded, and bar-coded) is associated with one or more of the transceivers20 (IR or RF) on thedevice12 to make thattransceiver20 distinguishable from theother transceivers20 on or attached to thecomputing device12. Eachlabel22 helps identify the functionality of the associatedtransceiver20 to users of that andother computing devices12. In one embodiment, thelabels22 are permanently affixed to thetransceivers20 and identify the default transaction that is associated with interacting through thattransceiver20.
• Such a set of labeled[0081]transceivers20 illustrate a physical embodiment of a computer program “menu”—one such menu for eachcomputing device12 and for eachelectronic resource14—with eachtransceiver20 representing one menu item. If there arefewer transceivers20 than fundamental transactions performed by thecomputing device12, one or more of thetransceivers20 can represent a transaction class or type or instance, and the selection of one transaction class can appear as a computer program menu during the interaction process with that transceiver.
• In embodiments with the[0082]computing devices12 andresources14 that have multiple spatially separatedtransceivers20, the teacher can arrange or organize the classroom to optimize and to facilitate the flow of information between the teacher and the students. For example, eachtransceiver20 is given a label indicating a function of thattransceiver20, e.g. “Update Software Here”, “Get Homework Here”, “Turn In Homework Here”, “Get Test Here”, and “Turn In Test Here.”Transceivers20 for distributing today's homework and for collecting last night's homework can be positioned at a classroom egress through which the students necessarily pass.Other transceivers20 for distributing tests and for receiving completed answers can be situated near a security station (described below) that enhances testing security. Thus, rather than having to navigate a computer user interface to accomplish different functions, students and teachers can move spatially to the physical location of distinct, separate functionalities. Further, for each function, there can be an array oftransceivers20, to allow many students to use the function in parallel. For example, there can be three beaming points that support “turning in homework.”
• Shared Medium Transcievers[0083]
• Because[0084]such computing devices12 are portable and have wireless communication capabilities, their users can move about freely and remain part of thenetwork2. Further the users may be able to communicate without their messages flowing through a central hub. Networks that operate without a coordinating central hub are conventionally designated “ad hoc.” Consequently, the wirelessdata communication network6, of whichsuch computing devices12 are a part, is generally referred to as a wireless Mobile Ad-Hoc Network (MANET).
• Thus the[0085]computing devices12 can have a shared-medium wireless networking transceiver (e.g., IEEE Standard 802.11). By shared medium, we mean that generally speaking all messages can be heard by all transeivers within range; directed point to point communication is not possible. Shared medium communications is typically added to a computational device in the form of anetwork card18,18′ (generally shared-medium transceiver18) in communciation withother networking cards18 and, for some embodiments, with thewireless access point16. Thewireless access point16 also has a shared mediumwireless networking transceiver18, typically in the form of a plug in card. The shared mediumwireless networking card18 and each of the short range point-to-point transceivers20,20′ are in communcation withmemory26 and aprocessor28. Accordingly, in the exemplary embodiment shown in FIG. 1,computing devices12′ and12″ each has four wireless transceivers: twoIR transceivers20, one short-rangePAN RF transceiver20′, and one sharedmedium tranceiver18; and thecomputing device12 has two transceivers: anIR transceiver20 and a shared-medium transceiver18.
• In[0086]networks2 withelectronic resources14, eachelectronic resource14 includes one ormore IR transceivers20 and awired network card24. Thewired network card24 is wired to thewireless access point16. Instead of thewired network card24, theelectronic resources14 can include a shared-mediumwireless networking transceiver18. In such embodiments, thecomputing devices12 can engage in wireless communication with theelectronic resources14 directly with thetransceiver18, instead of by way of thewireless access point16. In the exemplary embodiment shown in FIG. 1, theprinter14,projection display14′, androbot14″ each have anIR transceiver20 and awired network card24 connected to thewireless access point16.
• Not all students and teachers are necessarily always connected to the[0087]MANET 6 or to each other. For example, students can leave the classroom with their devices. Also, the members in a group of students do not need to be congregated in a single location, but can move to and work at distributed locations in the classroom
• Protocol Stack[0088]
• Network communication among the[0089]computing devices12 andresources14 is generally conceptualized in terms of protocol layers, such as the physical, data link, transport, and session layers, and such protocol layers form a protocol stack. FIG. 1A shows one embodiment of aprotocol stack30 by which thecomputing devices12 canelectronic resources14 communicate with each other.
• The protocols used at the lower layers of the[0090]protocol stack30 depend upon the type of physical medium over which thecomputing devices12 communicate. For example, the lower layers of theprotocol stack30 for IR communications include an IRDA-compliant (Infrared Data Association)physical layer32 and an OBEX (Object Exchange)session layer34 that runs over the lower layer of IRDA. The lower layers of theprotocol stack30 for RF communications include an RFphysical layer46, a TCP/IP transport layer48 that runs TCP/IP over wireless technology for communicating over short-range radio links, such as Bluetooth, 802.11 (b) or HomeRF. Alternatively, RF or IR communications may use an alternativemedium control protocol50, such as Hip Hop multicast. Hip Hop multicast and share pairs work well together because the Hip Hop multicast addresses refer to a channel in the shared medium, not acomputing device12, and share pairs control whichdevices12 can send or recieve messages from a particular channel.
• For IR and RF communications, the other layers of the[0091]protocol stack30 include acontract layer38 that manages filtering, packaging and security viacontracts36, adata migration service54 which manages acache46 of recently transmitted messages, acontent routing layer40, and anapplication layer44, which may utilize a ClassSync modeling language (CML) described in more detail below.
• As described in more detail below,[0092]
• the[0093]contract layer38 recieves contracts that have been beamed to its computing device and stores them;
• the[0094]contract layer38 subsequently filters communications based on contracts associated with such communications;
• the[0095]data migration layer54 caches messages and responds to queries fromother devices12 to describe and potentially retransmit cached messages;
• the Hip Hop (or multicast packet hop)[0096]layer50 provides a protocol for routing packets through thenetwork2 in the case where information is transmitted and received via Hip Hop multicast;
• the[0097]content routing layer40 associates contracts with messages before transmission, and associates application handlers with messages after reception; and
• the class[0098]modeling language layer44 specifies an underlying architecture upon which applications can draw in presenting to users a graphical or procedural language that systematically describes the various patterns of classroom interactions that are planned for particular classroom activities.
• During operation, software executing on a[0099]computing device12 prepares a document for transmission to anothercomputing device12 over thewireless network6. Every document transmitted over thenetwork6 includes a label or identifier that identifies a corresponding contract. Application software may associate the contract and document directly, in which case the next layer (i.e., the content routing services layer40) can be skipped. If the application software does not associate a contract with the document, the document next passes to the content-routing services layer40. At thislayer40, a process chooses an appropriate contract for the document, by analyzing the document and any descriptors the application has made available. When the document passes to thecontract layer38, software operating at thislayer38 determines whether the document can be sent over the network communication medium. If so, the document is processed at the appropriate lower layers of theprotocol stack30 based on the type of communication medium (IR or RF). Consequently, the document is passed to the network communication medium with an identifier corresponding to the contract associated with the document. Additional information may be passed to the lower layers as necessary to enact the transmission, such as a multicast IP address associated with the contract.
• A[0100]computing device12 receiving the document over the network communication medium processes the document at the lower layers of theprotocol stack30. Again, the particular protocol layers processing the communication depend upon the type of communication medium over which the communication is received. For example, if an IR communication is conveying the document, the IRphysical layer32 and an OBEX/IRDA layer34 process that communication in succession.
• At the[0101]contract layer38, software determines whether to pass the document to a higher layer of theprotocol stack30. Prefiltering criteria may be used before contracts are applied. One prefiltering criterion can be whether the multicast IP address associated with the document is a multicast IP address that the receivingcomputing device12 is permitted to process. Another prefiltering criterion can be whether an identifier or descriptor accompanying the document identifies content that the receiving device is permitted to process. Other prefilter criterion can be used to filter the communication. If the communication does not satisfy the prefiltering criterion or criteria implemented at thecontract layer38, only thedata migration services54 can further process the communication; from the point of view of application layers40 and44, the communication is discarded.
• If the communication passes the above described “pre-filtering”, the contract layer software determines whether the receiving[0102]device12 has a contract with a identifier that matches the contract identifier associated with the document. Without the contract, the receivingcomputing device12 is unable to process the communication further; only thedata migration services54 can further process the communication; from the point of view of application layers40,44, the communication is discarded. If the receivingcomputing device12 has the matching contract, the communication is then processed in accordance with the terms of the contract, as described in more detail below. If permitted by the term or terms of the contract, the document passes to thecontent routing layer40, which determines the content of the document (e.g., homework) and routes the document to the appropriate software for handling that content, such as an application program that collects and grades homework.
• Contracts[0103]
• In accordance with the principles of the invention, the teacher (or other leader) enables and controls distributed communications, access to network resources and document flow over complex network topologies using contracts to assign capabilities among the students. In general, a contract defines the rules of communication; a[0104]computing device12 without a contract cannot communicate. More specifically, a contract creates a capability of a student'scomputing device12′ to do some action, subject to the various parameters established at transmission (e.g., time, controlled device address, etc.) of that capability.
• Generally speaking contracts are paired with each contract in a pair containing reciprocal terms. One contract may allow transmission; the other may allow receiving; and both contracts have identical terms with respect to the kinds of content they pertain to. By giving a first student one contract and a second student another contract, both contracts belonging to the same share pair, the teacher can regulate the kind of sharing those students engage in. Since from the teacher's view, the control of sharing is the object of interest (and the paired contracts are instruments to that end), we use the term “share pairs.”[0105]
• Each contract has an identifier, and all contracts implementing the same share pair use the same identifier. In one embodiment, the contract identifier is a human-readable text string that describes the intended communication in a concise way. For example, if the classroom of students has been divided into groups, each group can have a unique name (e.g., “bluebirds”). Accordingly, contracts for the share pair that controls communication among this group can have an identifier that is the text string “bluebirds”.[0106]
• This identifier can be used at the[0107]contract layer38 to filter communications received over the network communication medium.Devices12 that do not have a contract with the identifier “bluebirds” do not pass communications with this label to theapplication layer44.Devices12 that do have a contract with the identifier “bluebirds” will ensure that the communication is allowable under the terms of the “bluebird” contract in the memory of thatdevice12. Only after all such terms are met, does thecontract layer38 pass the communications through to theapplications layer44. Thus, attaching an identifier with content supports rule-based application-level processing of communications.
• In general, teachers create share pairs and distribute the contracts within the share pairs to students, and the students associate the contracts they receive with particular communications (e.g., documents and messages) that are transmitted over the[0108]network2. To achieve these functions, theteacher device12 is equipped with application software for defining the terms of the contracts (described below), and thestudent devices12′ with application software that enables the student to select and incorporate the identifier of the selected contract in a communication. As an example, a student can choose a contract for association with a particular communication based on the content of the communication. For example, a student selects a contract labeled “Homework” with a particular communication that contains “homework.”
• The contract includes information (i.e. terms) that a[0109]recipient computing device12 orresource14 can query to determine if data associated with the contract can be processed by the next protocol layer. That is, the set of all contracts resident in memory on acomputing device12 define (1) the possible data flows through which all data received by lower protocol stack layers are passed to applications at the application layer, and (2) the possible data flows through which all data queued for transmission by higher protocol stack layers are passed to transport layers. The contracts operate as a filter of all incoming and outgoing communications.
• The contract information (also referred to as conditions or terms of the contract) includes, but is not limited to, one or more of the following components. By these various types of contract information, a limitless variety of contracts are possible.[0110]
• An item selector component provides a name to the contract, such as “homework”, “handout”, “quiz”. In general, the item selector is a short name that is displayed to the student on a user interface, such as a pop-up window listing various types of contracts with which to associate to a particular communication.[0111]
• A metadata component indicates a type or category of data that a[0112]computing device12 having the contract can run. The metadata can specify one or more of a plurality of possible types, including classroom-based custom types (such as homework, test, quiz, group work), the MIME-type (Multi-purpose Internet Mail Extensions) of the data, and data-descriptors based on the content of the data.
• A temporal component indicates whether the[0113]computing device12 can now perform the capability associated with the share-pair. In one embodiment, the temporal component is based on one or more temporal parameters, such as expiration date, time of day, month of year, duration (e.g., a metadata component of type “test” may have a time limit of two hours), or other compound temporal parameters. Capabilities given to acomputing device12 by this component have a temporal aspect. For example, a teacher can design a contract for use during a two-hour examination that enables thecomputing device12 to access aparticular network resource14 but expires upon expiration of the two hours.
• An I/O (input/output) type component specifies the type of input and output actions that the device having this contract is able to perform (e.g., read, write, or execute) the data attached to the contract.[0114]
• A length component specifies the size of messages that the[0115]device12 can handle.
• Another string specifies a user description of the contract. In one embodiment, this string describes the purpose and parameters of the contract.[0116]
• An alphanumeric field specifies a key used to encrypt data.[0117]
• A priority component specifies the priority of the share-pair that can be used, for example, to determine the queuing of communications, especially if the[0118]network2 becomes congested.
• Giving Contracts[0119]
• Upon deciding to assign a communication capability to a student (or to a group of students), the[0120]teacher device12 beams or broadcasts the contract for that capability to thestudent device12′. In one embodiment, the teacher approaches the appropriately labeledIR transceiver20 of the student'sdevice12′, aims the teacher'sIR transceiver20 of theteacher device12 at the student'sIR transceiver20, and initiates a beaming transaction between the twocomputing devices12,12′. As indicated above, if there arefewer transceivers20 on thestudent device12′ than interaction types, a menu can appear on the display of the teacher'sdevice12 offering the teacher a selection of interaction types to choose from. Therecipient device12′ stores the contract inmemory26 accessible to itscontract layer38. In a secure implementation, contracts should be stored in memory that can be read or written to only by code that implements thecontract layer38. That code can be protected from tampering by residing in a kernal not accessible to normal application programs on the device.
• Communication with regard to the[0121]student device12′ has been described. In one embodiment,resource devices14 may also be given a contract within a share pair. For example, the teacher may want to regulate communications between a student and a printer. To this end, upon completing the beaming interaction with thestudent device12′, with the student'sdevice12′ storing the share-pair inmemory26, the teacher moves to the intendedresource14 and similarly initiates a beaming transaction. When the transaction with theresource14 is completed, the student's use of theresource14 through the wireless andwired communication network2 is automatically enabled.
• In most cases, a teacher gives a contract to a student by a single communication. In one embodiment, the contract is packaged as an object and transmitted from teacher device to student device via the Object Exchange (OBEX) protocol. The object type is sent as part of the transmission, and makes it clear to the student device that the received object is a contract. The[0122]contract layer38 registers itself as the handler application for all incoming contract objects. Upon receiving a contract, thecontract layer38 processes the contract by storing the contract in memory.
• Distribution of the share-pairs can occur over a secure communication channel. To achieve the secure communication channel, the teacher, who regulates the distribution of the share-pairs, uses point-to-point IRDA to beam encryption keys to a[0123]student device12′ for its secure control channel. This point-to-point communication brings the teacher within proximity of the student; thus the teacher can use authenticate the student without cumbersome authentication procedures by simply observing the physical identity of the student. Accordingly, when a new student joins the classroom, the teacher can beam a communication to thenew student device12′, welcoming the student by name to the class, informing the student of her assignment to an team, and instructing her to join her team members. The new student can then join the team members and start synchronizing herstudent device12′ to share the documents belonging to the team.
• Giving Contracts as a Capability Exchange[0124]
• In an alternative embodiment, teachers can give contracts in the style of a capability exchange. This embodiment requires three communications, the teacher sends a query to the student, the student sends a response, and the teacher grants a contract. FIG. 2 shows an embodiment of this process in more detail. In this process the[0125]teacher device12 transmits a share-pair to thestudent device12′, in this example by IR beaming, to give thatstudent device12′ a specific capability (e.g., the ability to use an electronic resource14). To initiate the transfer of the share-pair, the teacher moves theteacher device12 to within range of thestudent device12′, and points theIR transceiver20 at theappropriate IR transceiver20 on thestudent device12′. Thelabel22 associated with thestudent IR transceiver20, if any, can assist the teacher in aiming the IR beam.
• In[0126]step100, theteacher device12 runs a configuration application that responds to the press of a pre-defined key by transmitting a first message over theIR transceiver20 of theteacher device12, using the OBEX (IrDA object exchange) protocol. According to the OBEX protocol, a content type of the first message, in addition to the contents of the first message, can be indicated as part of the transmission. The configuration application chooses the type of the first message so that thestudent device12′ receiving the first message associates the first message with a predetermined configuration handler application. For example, the contents of the first message can indicate that theteacher12 is initiating a capability exchange, and the type of the first message causes the receivingstudent device12′ to launch software to accomplish that exchange
• Upon receiving of the first message, the[0127]student device12′ runs (step104) the corresponding configuration handler application associated with the type of the first message. The first message and an indication of which IR transceiver20 (if thestudent device12′ has more than one transceiver20) passes as input to the configuration handler application. From the contents of the first message, the configuration handler application determines (step106) that a capability exchange is desired.
• The configuration handler application responds (step[0128]108) by sending a second message, of the type associated with the configuration application executing on theteacher device12, through thatIR transceiver20 by which thestudent device12′ received the first message. The contents of this second message include an indication of the interaction type that the configuration handler associates with theIR transceiver20 over which the first message was received. For example, the interaction type can be to send a document to a printer. If the receivingstudent device12′ supports more interaction types thanIR transceivers20, the contents of the second message include a list of supported interaction types.
• Upon receiving the second message, the configuration application executing on the[0129]teacher device12 creates (step112) a third message including a share-pair element (i.e., identifier and contract) appropriate to the interaction type. When the contents of the second message include a list of interaction types (rather than a single interaction type), the configuration application first presents the list to the teacher in human readable form and allows the teacher to choose one of the interaction types from the list. In one embodiment, the third message includes an IP multicast address, a password or other cryptographic element, and duration or time of validity for the third message. In this embodiment, the IP multicast address is deemed bound to the transmitted share-pair.
• The configuration application executing on the[0130]teacher device12 then transmits (step116) the third message, again with the message type that is associated with the configuration handler application on thestudent device12′. The configuration application on theteacher device12 also reserves (step120) a copy of the third message, suitably modified as regards any cryptographic element of the third message to correspond to the contents of the third message.
• Upon receiving the third message, the configuration handler application on the receiving[0131]student device12′ saves (step124) the contents of the third message inmemory26 for later use, invalidating any previous messages whose interaction type would conflict with this third message.
• The teacher then carries the[0132]teacher device12 to theIR transceiver20 of thetarget resource14 whose use the teacher wishes to provide to the student. Upon pressing the pre-specified button a second time, the configuration application on theteacher device12 conducts the interchange with theresource14 as described above. In particular, the configuration application sends (step128) a fourth message (identical to the first message), which is received by a configuration handler application on thetarget resource14. The type of the fourth message causes (step132) execution of a configuration handler application associated with that type. The configuration handler application on thetarget resource14 responds (step134) with a fifth message similar to the second message. The fifth message includes the interaction type or list of interaction types in the contents.
• Upon receipt of the fifth message, the configuration application on the[0133]teacher device12 confirms (step136) a match between the interaction type indicated in the copy of the third message held in reserve and the interaction type indicated in the fifth message. If the fifth message contains a list, the configuration application looks for a match with one of the interaction types in that list. If no such match can be made, the configuration application indicates (step140) an error condition to the teacher. Otherwise, the configuration application transmits (step144) the modified copy of the third message held in reserve as the sixth message, which the configuration handler application on thetarget resource14 by saving the contents of the sixth message inmemory26 for later use.
• At this point, and for the duration that the share-pair is valid, whenever an application executing on the[0134]student device12′ or on thetarget resource14 engages in a communication activity of the type indicated in the third and sixth messages, thestudent device12′ orresource14 runs the respective configuration handler application associated with that type. The configuration handler application engages thewireless network card18 to transmit to, and receive from, the multicast address indicated in the share-pair, and to engage the cryptographic element or password to confirm the propriety of the communication to the other computing device12 (or resource14) listening to the same multicast address.
• Security Manager[0135]
• In some circumstances, a teacher might want more global control of overall communication capabilities than is practical by managing individual contracts. Further the teacher might need to assert this global control more securely, for example, while proctoring an examination. To accommodate this desire, in one embodiment a “master” contract is sent to every student. This master contract supercedes all other contracts, and further filters communications. It may, in fact, turn off all subsequent communications for the duration of the examination. Further, in one embodiment, the notion of[0136]contract layer38 is expanded to also filter system events other than communications. Such acontract layer38 prohibits certain applications from being launched, for example.
• To create a secure environment for safe execution of handheld applications during defined class periods, the[0137]student devices12′ include firmware that implements thesecurity manager56 within thecontract layer38, referred to in FIG. 1A and described in more detail below. In brief overview, eachstudent device12′ that supports thesecurity manager56 has an identifying logo, and is responsive to a challenge that demonstrates the authenticity and tamper-free status of thesecurity manager56 on thatstudent device12′. While in a security-managed mode (hereafter secure mode), thestudent computing device12′ provides an indicator that a teacher or proctor can easily detect (e.g., by glancing at acomputing device12′ with a flashing LED).
• Generally, invoking the[0138]security manager56 follows the “capabilities exchange” variant of granting a contract as described above. That is, the teacher sends a message (“a challenge”) to the student device. Based upon the student response, theteacher device12 determines whether thestudent device12′ has avalid security manager56 in itscontract layer36. If theteacher device12 decides affirmatively, theteacher device12 sends thestudent device12′ a contract (i.e., the master contract) that supercedes all other contracts and lasts the duration of the examination. If theteacher device12 decides negatively, the teacher takes steps to prevent the student from using thestudent device12′ during the examination (e.g. by taking the device away).
• More specifically, FIG. 2A illustrates an embodiment of a process of placing and operating a[0139]computing device12 in a secure mode for engaging in security-sensitive activities, such as administering a test to one or more students, in accordance with the principles of the invention. In this process, each student uses astudent device12′, having thesecurity manager56, to take the test. (Thesecurity manager56 can be transmitted to thestudent device12′ at the time of taking the test). Thestudent device12′ has identifying label attached to it, marking thestudent device12′ as eligible for use during the test, or marking the device for use by a particular student during the test. Such a label makes it easy for the test proctor to detect that students have exchanged devices, or are using an ineligible device during the test. Thestudent device12′ is connected to thenetwork2 by a wired or wireless physical link. Wired links can be peer to peer or over thenetwork2. For wireless links, thestudent device12′ can communicate with IR or RF signals.
• Before the start of a test (or of an otherwise restricted class session), several security measures are taken to ensure the authenticity of the test taking process. As a first measure, each student taking the test enters (step[0140]58) a secure examination area with his or herstudent device12′. In one embodiment, the students necessarily pass near a security station in order to enter the examination area to sign in for the test. The security station can be, for example, a laptop computer, desktop computer, a portable computing device (e.g., a handheld), a wireless communication point, or an infrared beaming port controlled by a server system connected to the wired network10. A person (i.e., the proctor) can monitor the security station to observe the class members to ensure they follow the security procedure.
• When the student signs in for the test or passes near the security station, the proctor sends (step[0141]60) a request to thestudent device12′ to enter a secure mode of operation. Thestudent device12′ issues (step62) a reply to this request, confirming that thestudent device12′ has entered the secure mode. In some embodiments, this confirmation includes one or more of a certificate of authenticity, a version number, and a certificate of integrity of thesecurity manager56 executing on thestudent device12′. The confirmation can include characteristics of thestudent device12′, such as the make, model, operating system, resident applications, and databases of thatstudent device12′. Such checking of the hardware of thestudent device12′ operates another measure of security. Execution of thesecurity manager56 may, for example, detect the presence of a powerful algebraic solver that is not allowed during an algebra test.
• The transmission of the request and reply can be by an IR beam, RF communication, or by wired communication. The face-to-face transmission of the share-pair and security program to the student provides another measure of security that authenticates the test taking process. Presumably, the teacher or proctor can identify the student by sight or by personal identification (i.e., student ID).[0142]
• When properly in the secure mode of operation, the[0143]student device12′ is able to respond correctly to a challenge, such as the pressing of a particular key or keyboard combination or the receiving of a particular wired or wireless communication from the security station. Instep64, thestudent device12′ receives a challenge issued by the security station (or proctor) and computes (step66) a response that demonstrates the authenticity and integrity of thestudent device12′. Only thosestudent devices12′ operating in the secure mode of operation can compute the correct response. Further, throughout the administration of the test, should the proctor detect IR and RF traffic from an unregistered (i.e., non-compliant)student device12′, the proctor can challenge thatstudent device12′ to see if thestudent device12′ has the security manager in place. If not, thestudent device12′ is confiscated. In one embodiment, the security manager can lock out the repeating of traffic, and thus any detected traffic is an indicator of the presence of anon-compliant student device12′.
• In[0144]step70, an indicator is activated on thestudent device12′ that verifiably shows that thestudent device12′ is operating in the secure mode of operation. In one embodiment, the indicator is a sticker that the proctor affixes to a visible surface of thestudent device12′ after receiving confirmation that the computing device is operating in the secure mode. The sticker can be chosen to be unique to the test event, and be hard to guess by class members before the event. In another embodiment, the indicator is a detectable output produced by thestudent device12′ upon entering the secure mode. For example, the indicator can be a visual display on thestudent device12′, such as a flashing LED (light-emitting diode), an emitted continuous or periodic sound, or a wireless transmission (IR or RF). In yet another embodiment, the indicator is that thestudent device12′ has the ability to respond to a challenge made by the proctor. Thus, the proctor can determine at a glance if any student was using astudent device12′ that was not in the secure mode (e.g. from the absence of a flashing indicator), and could confiscate thestudent device12′.
• When operating in the secure mode, the[0145]security manager56 implements the contract given to it, and this contract may lock out student use of certain features of theirstudent device12′ during the test, such as locking out communication features. The request to enter the secure mode of operation includes information about which functionalities, modalities, or capabilities on thestudent device12′ are to be restricted or unrestricted. Accordingly, thesecurity manager56 uses the operating system of thestudent device12′ to impose one or more restricted capabilities, functionalities, and modalities. In some embodiments, the restricted capabilities include communicating over particular physical links (e.g., IR, RF, and wired links). Communications on these links can be filtered by IP address and socket. As examples of other restricted capabilities, the secure mode of operation can prohibit thestudent device12′ from communicating with a particular protocol (e.g., Bluetooth, 802.11, TCP/IP, OBEX, IrDA, HTTP, FTP) or with particular Internet hosts, which can be screened by protocol type, domain name or destination IP address. Other examples of restricted capabilities include prohibiting usage of particular kinds of system libraries on thestudent device12′ and usage of information transfer mechanisms such as copy and paste via a clipboard.
• Examples of restricted functionalities include prohibiting the[0146]student device12′ from launching any application programs or particular application programs, from switching modes in an application, from storing any data or a particular type of data in memory (e.g., in a clipboard) of the device, and from reading any data or a particular type of data from memory. The operating system can use the application signature to filter the launching of application programs, and database type and record length, for example, to filter reads and writes of data. Other examples of restricted functionality include prohibiting thestudent device12′ from installing software on thestudent device12′, setting system preferences, and blocking the ability to use hardware add-ons. Restricted modalities can include prohibiting start-up after an interrupt, system re-boot, or reset of the device. In such types of events, a secure session persists across events.
• Restrictions can be customized to[0147]specific student devices12′, depending on whether permission is given to have the use of thestudent device12′ monitored and stored for later analysis by thesecurity manager56. That is, a student can potentially be granted additional privileges in exchange for that student granting a right to log the private data of the student to an archive. For example, the student may request ability to read a database of notes during the exam, which the proctor can grant in exchange for a copy of the database, so that the database could be later reviewed for violation of the terms of the examination.
• In some embodiments, the restrictions of capabilities, functionalities, or modalities are specified by rules. The rule language can match and filter content by a comparison operation and can specify multiple rules. These rules can be resolved by a metarule. The metarule can choose, for example, the most permissive or least permissive rule, or the most or least general rule.[0148]
• Those restrictions applied to a specific application on the[0149]student device12′, in one embodiment, depend on whether that application can provide a certificate that enables thesecurity manager56 to confirm the origin and integrity of the application. In another embodiment, the restrictions applied to the specific application depend on a test that thesecurity manager56 makes of that application, such as testing its authenticity and integrity. In this embodiment, the request from the security station indicates those restrictions to be applied to the specific application if the application passes the test. The application-specific restrictions are communicated in a language agreed upon by the security system vendor and the application vendor, but are specific to the application, and particular to the capabilities of the application. Examples of application-specific restrictions include prohibiting classes of mathematical functions, such as trigonometric functions, computer-algebra-system operations and classes of textual functions, such as spell check, grammar check, dictionary access.
• The rules specify the restrictions in a rule language that allows matching of general rules to specific situation. The general rules can match characteristics of an application, of data, of a communication link, of a communication protocol, of a system library, of an information transfer mechanism, of a host computer address, of a message sent to a host computer, or of information received from a host computer, of a buddy list (for a test where students work in teams).[0150]
• Also, the[0151]security manager56 can define different security levels for specific types of subject matter. For example, one security level can allow arithmetic, another the evaluation of algebraic functions, another the symbolic manipulation of algebraic functions, yet another the graphing of algebraic functions, and the like. Further, signed applets can be granted more permission than unsigned applets, and an applet is allowed to be signed (by a certifying authority) if the applet conforms to security manager guidelines (e.g. followed the subject matter security levels).
• After the[0152]student device12′ is in the secure mode of operation, the security station beams (step74) a specific contract (master) that nullifies (for a predefined period) all other contracts that are be present on thestudent device12′. Consequently, thestudent device12′ is assured to have the proper contracts in force at the time of taking the test. Another measure of security is achieved by storing this contract in hardware of thestudent device12′ that cannot be tampered with by the student. The contract can reside in inaccessible hardware of the networking card (wireless18 or wired24) or be maintained in hardware of thestudent device12′ accessible only at the operating system level.
• The contract also includes a unique encryption key that the[0153]student device12′ uses to communicate with the proctor. The encryption key can be a simple password or the public half of a public-private key encryption system. By this key, the security station (or proctor) determines (step78) that thestudent device12′ accepted the contract because the key, which cannot be tampered with by the student because it is stored in the inaccessible hardware, is used when thestudent device12′ replies to the security station.
• The security station beams (step[0154]82) the test and a second specific contract having a contract and a unique key. As described above, the key passed with the contract shows (step86) that the hardware of the computing device has accepted this contract. Also, the unique key links a particular completed test to aspecific student device12′, thus preventing one student from submitting a completed test twice; once for himself, and again for a friend.
• In one embodiment, the[0155]student device12′ participates in a security checkout procedure upon leaving the restricted area or restricted situation (i.e., test). This checkout procedure can involve a communication between thestudent device12′ and the security station (e.g., a log ofstudent device12′ activity might be transmitted.)
• Share Pairs Allow Teachers to Dynamically Control Communications[0156]
• By creating share pairs and giving different contracts of a share pair to different devices, the teacher dynamically controls the interactions among[0157]computing devices12 andresources14 by moving about the classroom and interacting with thestudent devices12′ andresources14 therein. The class of capabilities that the teacher can assign through the beaming of share-pairs provides a diverse range of interactive learning environment activity structures. For example, the teacher may want to define six groups of four students in the classroom for a group problem-solving activity. The teacher can flexibly define those groups in real-time by walking around the classroom and beaming a group-related share-pair to each student in a group. Then the teacher can beam to one student in each group a “leader” capability that enables that student to pass to the other students in the group specific capabilities, such as use of a probe for collecting data, the use of a display to show their work, and so on.
• Share-pairs make tractable a problem that teachers may have in planning and performing a broad range of classroom interaction topologies. By distributing share-pairs throughout the classroom, the teacher enables and controls secure classroom communication, resource access, and document flow in a way that is easy for the teacher to specify and enact. Teachers can use peer-to-peer beaming (which is easily understood to designate particular computing devices[0158]12) to shape the topology of shared medium (e.g., Ethernet or wireless) communications, wherein network addresses do not bear an obvious correspondence to physical entities).
• In general, share-pairs are able to capture a wide range of classroom interaction patterns using a few primitive share-pair topologies. Specifically, four fundamental share-pairs, when combined in a plurality of configurations, allow a teacher to specify a broad range of classroom interaction patterns.[0159]
• FIGS.[0160]3A-3D illustrate these four fundamental share-pairs. In each of FIGS.3A-3D, a box with a label denotes the share-pair, the block with a “T” denotes a transmitter of a message, and a block with an “R” denotes a receiver of the message. The message is any electronic communication, which can include attached data, electronic files, etc.
• FIG. 3A shows a “messaging” configuration for share-[0161]pair150. For this share-pair configuration, theshare pair150 has two contracts. One contract, given to thetransmitter152, grants a transmit capability but no receive capability. The other contract, given to thereceiver154, grants a receive capability but no transmit capability. Both contracts have the same identifier. Thecontract layer38 on thetransmitter152 evaluates the transmitter contract 1) to accept any message having the contract identifier received from an upper protocol layer, for forwarding to the communication medium, and 2) to reject any message having the contract identifier received from a lower protocol layer. Conversely, thecontract layer38 on thereceiver154 evaluates the receiver contract 1) to reject any message having the contract identifier received from an upper protocol layer, and 2) to accept any message having the identifier received from a lower protocol layer, for forwarding to a higher protocol layer.
• During operation, the transmitter “T”[0162]152 sends a message over thenetwork2. The message includes the identifier associated with the contract given to thetransmitter152. The receiver “R”154 receives the message over thenetwork2, uses the identifier to access the contract given to the receiver154 (stored in memory26), evaluates the contract, and processes the message, provided the terms of the receiver's contract so allow.
• In another embodiment, the same “full” contract, including both those terms that apply to the[0163]transmitter152 and those terms that apply to thereceiver154, is given to both thetransmitter152 and thereceiver154. In this embodiment, each device is given a means of distinguishing which terms apply to that device. In yet another embodiment, one device (e.g., the transmitter152) has the full contract, with the means of distinguishing the applicable contract terms for that device, and the other device (e.g., the receiver154) has the contract with only those terms applicable to that device (i.e., the receiver contract).
• FIG. 3B shows a “distributing” configuration for share-[0164]pair158. For this share-pair configuration, theshare pair158 has contracts like those used in the “messaging” configuration, however the teacher grants the “T” contract to only one computing device and the “R” contract to a plurality of computing devices. Each granted contract has the same identifier. The transmitter “T”156 sends a message over the network2 (e.g., by point-to-point IR beaming or RF broadcasting). The message includes the identifier associated with the transmitter's contract. A plurality ofreceivers160,160′,160″ (generally160), each denoted by “R”, receives the message over thenetwork2. Eachreceiver160 then uses the identifier to access the contract given to thatreceiver160, evaluates the contract, and processes the message, provided the terms of the receiver's contract so allow. Typical uses of a distributing configuration share-pair are for sending the same object to all students (such as a homework assignment), sending different, unique objects to each student (e.g., individualized tests), and sending parts of objects to students (such as sending out one part of a class project that is to be assembled by the whole class).
• FIG. 3C shows a “collecting” configuration share-[0165]pair164. For this share-pair configuration, theshare pair164 has contracts like those used in the “messaging” configuration. In this case, the “R” contract is granted to only one computing device, and the “T” contract to many computing devices. Each granted contract has the same identifier. A plurality oftransmitters162,162′,162″ (generally162), each denoted as “T”, sends a message over thenetwork2. The message has the identifier associated with the transmitter's contract. A receiver “R”166 receives the message over thenetwork2, uses the identifier to access the contract given to thereceiver166, evaluates the contract, and processes the message, provided the terms of the receiver's contract so allow. A typical use of this configuration is for the student (here using transmitter162) to hand in an assignment to the teacher (here using receiver166). Examples of collecting include collecting a specific object from each student (such as a homework assignment or test), adding by each student to a larger structure (synchronizing a group or class presentation), and tabulating a set of individual responses (such as voting).
• FIG. 3D shows a “sharing” share-pair configuration. In this configuration, the[0166]share pair168 contains only one contract, and the contract grants both transmit and receive capabilities. Everydevice12 gets the same contract. In this configuration, each configureddevice12 transmits and receives all data intended for this share-pair168. A typical use of this configuration is for students who are working together on a project to share their findings with the other students in their group (i.e., having the same contract). Examples of sharing include those described for the distributing and collecting configurations.
• FIG. 4 shows an embodiment of a classroom communication topology that has four students named Tom, Bill, Nick, and Sue. The[0167]computing devices12′ of these students are configured with three share-pairs as follows. Tom has two contracts labeled “collect #268” and “distribute #539; Nick and Bill each have three contracts labeled “collect #268”, “distribute #539”, and “share #02, and Sue has one contract labeled “share #02”.
• The contract labeled “collect #268” enables Tom to collect messages from Nick and Bill, the contract labeled “distribute #539” enables Tom to distribute messages to Nick and Bill, and the contract labeled “[0168]share #02” enables Sue, Nick, and Bill to send and receive messages to and from each other. In this exemplary classroom, it may appear that all students (Tom, Bill, Nick, and Sue) can share all messages with each other because Tom can distribute a message to Bill (per contract distribute #539), and Bill can share with Sue (per contract share #02). However, Sue does not possess the contract named distribute #539, so Sue cannot process any message distributed by Tom with the distribute #539 contract. (Note, the message from Tom to Bill includes the distribute #539 label, and Sue lacks the appropriate contract, and thus a contract, that would enable Sue to process the message when the message is received.) In this way, a teacher can specify a set of configurations that allows some documents to be shared by the class (using a “share” contract that includes all class members), whereas other documents may be distributed to specific class (or group) members (by specifying the appropriate contracts).
• In general, when a[0169]computing device12 transmits a communication, that communication is associated with a particular contract by an identifier (or label). The communication is received at thecontract layer38 from a higher protocol layer in theprotocol stack30. At thecontract layer38, thecomputing device12 determines whether to present the communication to the communication medium based on at least one term of the contract associated with the identifier. Upon determining to present the communication to the communication medium, the identifier is incorporated in the communication before the communication is forwarded to a lower protocol layer (e.g., the multicast packet hop (or hip hop) layer50) in theprotocol stack30 for placement on the network communication medium.
• When a[0170]computing device12 receives a communication, the lower layers of theprotocol stack30 initially handle that communication. An identifier accompanies the communication; this identifier is associated with a particular contract. The communication passes to thefiltering layer54, which extracts the identifier from the communication and determines whether to present the communication to a higher layer (e.g., the content routing layer40) in theprotocol stack30 based on at least one term of the contract.
• A Classroom Modeling Language (CML)[0171]
• In a typical classroom, the teacher and students using their[0172]computing devices12 participate in a variety of interactive activities. A classroom modeling language (CML) provides a method for systematically describing, from a teacher or activity designer's perspective, the various patterns of classroom interactions that are planned for particular classroom activities. The CML specifies an underlying architecture, upon which a graphical or procedural language can be built, that accommodates the specification of a complex set of overlapping share-pairs. In general, the CML provides a means by which the teacher can author and distribute contracts of the appropriate type to implement a desired workflow pattern. Such software for authoring and distributing contracts reside on theteacher device12 and function at theapplication layer44.Student devices12′ can also have CML-based applications operating at theapplication layer44. For example, thestudent devices12′ can have a CML-application that responds to messages from the teacher, instructing the students to activate and deactivate particular activities, thus changing the pattern of activated contracts and content routing choices.
• The CML supports three types of actors: persons, group managers, and bots. (Every actor in the network is a case of one of these actors.) A person is an individual using one[0173]computing device12. A group manager is the hub of an interacting group of actors. In one embodiment, groups of actors are specified by share-pairs. A bot is a computer agent, and in one embodiment can be described by the Open Agent Architecture. Each actor has descriptors (metadata), data, and one or more transient states associated with that actor. Table 1, below provides a description of each of the properties of each type of actor.

  TABLE 1
  CML Actors
  Properties of CML Actors

  			Transient
  Actor	Descriptors	Data	states
  All	ID, repository	List of associated	Transfer
  Actors	address	data objects	Queue,
  			Linkage
  Person	gender	List of group	Activity
  	class rank	affiliations as ordered	progress
  	learning type	pairs: (group ID (as
  	etc...	specified by the
  		share-pairs they are
  		in), role(s) played in
  		group)
  		Goals
  Group	Topology	List of members as	Activity
  Manager	Purpose/type	ordered pairs: (actor,	progress
  		role)
  		List of group
  		affiliations as ordered
  		pairs: (group ID,
  		role(s) played in
  		group)
  		Goals
  Bot	Description of	Schedule	Current task
  	capabilities
  	(OAA style)

• Each actor has an ID. An “ID” can include several parts, including a real world name, a unique system ID, and an email address. Also, a storage address is associated with each actor. This address is not a literal machine address, but rather an identifier that allows data and the metadata describing the actor to be recorded or retrieved to and from the appropriate location. In one embodiment, the identifier is a Uniform Resource Name, or URN. The address can be associated with multiple machine addresses. For instance, a student's data can be saved on the[0174]student device12′, and queued for transfer to a central server machine each time the student “saves” a data object.
• Each actor has a list of data objects associated (i.e., viewed, controlled, or owned) with that actor. In one embodiment, one data object is an XML document containing the actor's descriptors.[0175]
• Each actor includes two transient states—a Transfer Queue state and a Linkage state. The Transfer Queue state is a list of data objects currently scheduled for transfer between this actor and another actor. Linkage state is a list of all links to or from the actor, where to be “linked” effectively means to be “logged in.” For example, if a student turns on his[0176]student device12′ in the presence of theclassroom network2, the student automatically logs in (is linked to) to the group “Class.” Consequently, that student's linkage list has a link to the Class. Note the “Class” itself is a special case of a group—all students are members with the role of “Student,” and the teacher is a member with the role of “Teacher.”
• One type of actor is a person. “Person” refers to not just to the human being, but also to the[0177]computing device12 that the human being is currently using to interact with thenetwork2. Thus, the ID of a person can be a combination of the person's name and an identifier associated with the person'sdevice12. In general, the repository address for the person is thecomputing device12, but that does not have to be the case. In addition, a person has other descriptors used for grouping purposes, such as gender, class rank, and learning type.
• Generally, a person is a student or a teacher. A teacher is a special case of a person, in effect, a “superuser” of the[0178]network2, who can link directly to any actor and edit or create group affiliations for any actor. In one embodiment, the teacher achieves the linking, editing, and creating by creating share-pairs for each student.
• Each person is associated with data objects and with a list of groups. In one embodiment, this list of groups corresponds to a list of share-pairs that the person belongs to. This list of groups also includes the person's role or roles in that group. A person can also have a list of goals that describe what the person is ultimately working toward in the current activity. Also, a transient value (“activity progress”) is a measure of the person's performance on the current activity.[0179]
• A group manager is an actor that keeps tracks of a group and manages the group's resources. A group is two or more persons or groups that can become linked via a network topology, described below. In one embodiment, the group manager stores information about each share-pair distributed to the students and resources.[0180]
• The group manager is not associated with a particular computing device—one[0181]device12 or a set ofdevices12 can operate as a repository for a group. The group manager is associated with an interaction topology and, optionally, a defined purpose or type for the group.
• The group manager maintains a list of the actors that can link to the group manager and the role(s) that each actor plays. The group manager also has a list of groups that the group manager can link to, and the roles that the group (subgroup) plays in those groups (supergroups). The group manager can have information describing the goals of the group. Like a person, a group manager can have a transient value representing the group's present state of progress on the task at hand.[0182]
• A bot is an independently operating agent (e.g., process) in the[0183]network2. In addition to having an ID and a repository, a bot also has a set of descriptors that describe the bot's capabilities. Each bot is associated with a schedule that indicates what operations the bot performs and when the bot performs them. Each bot can have a transient state representing its current activity, and another transient state measuring the bot's progress on that activity.
• The actors in the[0184]network2 interact with each other through data objects. Data objects exist in the distributednetwork2 and can be shared by multiple actors. Each data object has the following properties: 1) an identifier, 2) ownership, 3) semantic type, 4) a list of parent and child IDs, 5) a modification history, 6) a list of views and controllers, and 7) permissions.
• The combination of a data object's ID and its physical storage location enable the distributed[0185]network2 to locate the data object. In one embodiment, the storage location is specified as an URN.
• Actors can own data objects. Although many actors can view or control access to a data object, only the owner may delete the object or set the data object's permissions.[0186]
• The semantic type of a data object is, for example, the data object's class (in Java terminology). A given semantic type has certain capabilities (public methods) and certain data values (fields and accessors) contained within it. These capabilities determine what kinds of views and controls can be created in relation to the data object.[0187]
• From the view of a given data object, the given data object can reference other data objects as part of the given data object's data, and these referenced data objects are the given data object's children. Other data objects can reference the given data object as part of their data. These data objects are the given data object's parents. So, each data object contains a list of its children, to be able to access that data object's data when needed, and a list of its parents so that a parent can be notified if one of its children has been modified.[0188]
• Each data object maintains a modification history, as either a list of ordered pairs: (modification date, modifier), or as a complete underlying CVS-style (Concurrent Version Style) system, described below.[0189]
• Each data object can maintain a list of currently opened views and controllers, in the event that it needs to notify the views and controllers of changes to the model.[0190]
• Each data object maintains a list of individual people with “v,” “c,” and/or “t” (view, control, and/or transfer) access, and the specific access for each person. For example:[0191]

  	[000142]	Student A	--t
  	[000143]	Student B	vct
  	[000144]	Student C	vc-

• Each data object also maintains a list of groups with view (v) or control (c) access, and the access for each group. For example:[0192]

  	[000146]	Group A	vct
  	[000147]	Group B	vc-
  	[000148]	Group C	v-t

• In the above examples, a dash (“-”) rather than a “v”, “c”, or “t” indicates that the person or group does not have the permission.[0193]
• Typically, groups share data objects. In one embodiment, the distribution of share-pairs to students forms these groups. For data objects shared by a group, the CML resides on the group's repository, and any member in the group can request a view of it. There are four embodiments for controlling access to shared data objects: 1) synchronized access, 2) database-style, 3) CVS-style, and 4) distributed access.[0194]
• For synchronized access to a shared data object, only one actor can initiate a control session on this data object at a time. Other actors desiring to access the data object wait in a queue.[0195]
• For database-style access, only one actor can initiate a control session on a particular part of the data object at a time. The granularity of a “part” is determined by the logical structure of the data object under consideration. For example, in a database a “part” is typically a record, for a presentation a “part” can be a slide, for a word processing document a “part” can be a paragraph or a section. All group members can view all parts of the data object at once, but only one member can control a particular part.[0196]
• For a CVS-style (Concurrent Versions System) access, any member of the group can open a control session with the data object at any time. When each member is done with the data object, each member submits its new version of the data object for saving in the group repository. The CVS attempts to merge each new version of the data object with the present data object in the repository. In one embodiment, the CVS maintains a history of changes made to a data object.[0197]
• For distributed access to a shared data object, all views of the data object, including views in controllers, are real-time. When any actor makes a change to the object with a controller, the model on the service is modified and the changes propagate out to all open views.[0198]
• In a distributed-network environment, such as the[0199]MANET 6, all group members are not always located together in space and time. Therefore, to maintain distributed access, control privileges exist only when all group members are part of thenetwork2. Alternatively, the access control technique resorts to a CVS-style implementation, in which changes that were made are automatically noted and manually or automatically integrated into the data object.
• For synchronized, database-style, and CVS-style accesses, a change to the model when views are open can be handled by: 1) relying on the student or teacher to determine if their view is current, 2) sending a message to every view in the data object's list, 3) periodically checking the viewer application to see if the model has changed, and if so, downloading the new version, or 4) scheduling a transfer of an updated version of the view.[0200]
• Transfer queues handle the movement of data objects between actors. Each transfer queue is a list of transfers. Each transfer includes the following properties: 1) pointers (e.g., URNs) to the destination and origin of the data object being transferred, 2) a bit indicating the direction of movement (send or receive), 3) the current fractional completion of the transfer, 4) a bit indicating whether the transfer is a copy or a move, and 5) a bit indicating the transfer is destined to be a “mass mail” to the members of a group.[0201]
• There are two general kinds of transfer—download and exchange. “Download” is akin to putting a data object in a public FTP (file transfer protocol) folder and letting others know that the data object is available. “Exchange” is similar to emailing a file.[0202]
• A download is the case where a data object is made available to some group for transfer. (The transfer permission has been set for the group.) In one embodiment, an actor knows or can derive the URN of the data object in order to download it.[0203]
• An exchange involves active participation of an actor with the data object and actor who is to obtain the object. One actor initiates the exchange by sending a message to the other actor, requesting to send or to receive the data object (for which the recipient of the message does not yet have transfer access.) If the other actor agrees to the exchange, then a transfer is added to each actor's queue. Once a transfer is queued, the file system of the[0204]network2 completes the transfer.
• Messages are transient data objects that are stored locally until transferred, at which point the messages are deleted. Messages are a special semantic type of data object. The sender of a message does not have to wait for a recipient to accept it, as in the case of an ordinary exchange. The message is automatically transferred to the target. Some embodiments include various features with a message such as logging, receipt requests, dialogs, etc.[0205]
• Actors can be members of various groups, but they do not interact (i.e., perform transfers) with those groups until the actors become linked to the members of the group or to a group's group manager. To begin group interaction, an actor opens a link to the group manager. What happens next depends on the topology of the group's network. Regardless of network topology, the actor can send a data object to every member of the group in one transaction (mass mailing.) Once linked to the group manager, the actor can request data from the group manager, such as the member roster of the group and the present linkage.[0206]
• If group members cooperate via a client/server network, the group manager acts as “server” for the group. Recall that the group manager is associated with a repository. This repository serves as the shared “file space” for the group. Here, group members can post data that they want other members to download. Also, any data objects that are shared by the group reside in this repository.[0207]
• If an actor in a client/server group wants to send a data object to the entire group (mass mail), the following happens:[0208]
• 1) Actor A schedules a data object for transfer to group actor G, with the “mass mail” bit set.[0209]
• 2) The data object is transferred to the group repository.[0210]
• 3) Actor G schedules transfers to each other member of the group;[0211]
• 4) The data object is copied from the repository to each actor in Actor G's linkage, except to Actor A. The data object can be deleted from the repository.[0212]
• If the network topology of the group is point-to-point (P2P), then logging in to the group manager results in a link being created to each other member of the group. There is no “server” in this case. If a file is to be shared, a group member hosts the file on his or her[0213]own computing device12. In effect, there is no single group manager for group arranged in a P2P network topology—the group manager is distributed among the group members. In one embodiment, a copy of the group manager resides on everycomputing device12 in the group. In another embodiment, the group manager resides on a subset of computing devices (for instance, on the computing device of the person who is the designated “group leader”).
• A distributed group manager synchronizes itself. For example, when an actor logs in to the group, the group manager on that actor's[0214]computing device12 searches and finds other group managers in the P2P network. That actor's group manager then sets its own state to the state of those other group managers.
• For a group in a P2P network, the following occurs when a data object is transferred from an actor to the group:[0215]
• An actor A schedules a data object for transfer to group manager actor G;[0216]
• Group manager G schedules each transfer in actor A's transfer queue to each actor in Group manager G's linkage other than actor A;[0217]
• The data object is copied (or moved) to the repository of each target actor.[0218]
• Embodiments of P2P networks include networks that are limited, directed, or both. In a limited P2P network, a given actor links to a subset of the group (the limit is that the given actor does not link to the other members of the group). In a directed P2P network, a given actor can transfer in one direction to another actor in the group (this network is directional in that the other actor does not transfer to the given actor). An example of a group that is limited and directional is a “chain.” A chain is, in one embodiment, a linked list of actors, in which a given actor can receive data objects from only the actor immediately “upstream” in the list, and can send data objects to only the actor immediately “downstream” in the list.[0219]
• Actors participate in activities. An activity is the interaction amongst actors and data objects that is directed towards achieving one or more goals. Hence, to define an activity, a teacher or author defines an objective or goal, identifies who is to work on the activity to achieve the goal, and what the “input” data objects are to be. In some embodiments, the goal amounts to the creation of one or more “output” data objects. One example of a goal is to open a view to the input data objects.[0220]
• Activities can be chained or networked together to form a superactivity. This superactivity can be part of another chain or network of activities, which in turn is part of a yet another, higher-level activity. Subactivities are referred to as being nested within their superactivity.[0221]
• To chain activities, a linked list of activities is created. In one embodiment, the input data objects that are inputted to a given activity in a chain are the output data objects of the activity that linked to the given activity.[0222]
• Creating a network of activities is similar to creating a chain of activities, except that in the activity network there can be more than one link from the current activity to the “next” activity. At each branching point in the activity network, in one embodiment the student can choose the next activity. In another embodiment, the next activity depends upon the output data object from the current activity. Whether activities are chained or networked, a linked collection of activities is a directed graph.[0223]
• When a linked collection of activities is created, that linked collection becomes encapsulated in one superactivity. The “goal” of the superactivity is to complete all of the goals of the subactivities. The input data objects of the superactivity are the input objects of the first activity in the linked collection and the output data object of the superactivity is the output data object of the last activity in the linked collection.[0224]
• As described above, the teacher is the superuser of the[0225]network2. As the superuser, the teacher can, among other things, create groups. To define a group, the teacher creates a group manager for the group. This has two steps, assigning descriptors for the group manager, and assigning the group manager initial data.
• Creating any actor in the[0226]network2 begins by assigning values to the descriptors of the actor. An ID is created, then a network topology is chosen—Client/Server or P2P. If the group is a Client/Server network, then a repository address on thenetwork2 is defined for the group manager. The teacher can create a general description of the group—for example, “National Government,” “Research Team,” etc.
• The teacher also associates the group manager with data. There are three types of data associated with the group manager: 1) data objects; 2) a member roster; and 3) group affiliations. The teacher creates a list of URNs of the data objects that the group has at the start. Then the teacher creates a list of students that are a member of the group, and assigns each student one or more roles. If the group is to be a member of a larger group, the teacher identifies that group and assigns the subgroup's role in the supergroup.[0227]
• The teacher then clicks an “Enable” button, for example, to enable the group manager. How the CML system activates the group manager depends on the network topology of the group. For client/server networks, the CML system creates the repository for the group manager, and moves a copy of all the data objects assigned to the group, and an XML document containing the group's descriptors and membership, to this repository. Then a bot is scheduled to search the[0228]network2 and to find each student in the group, and to add the group and the role of the group members in the group to the student's group membership list.
• For P2P networks, a P2P group has no centralized repository. Here, the bot moves a copy of the data describing the group manager to each member of the group. The bot also puts at least one copy of each of the data objects assigned to the group to at least one of the group's member's repositories.[0229]
• When the teacher places a student in a group, the student receives a notification. In one embodiment, the student's own group membership list sends a message to the student when the list is altered. In another embodiment, the bot that modifies the group membership list puts a message in the student's mailbox.[0230]
• Upon placing a student in a group, the teacher can find out the status of each student with respect to the current group of that student. For instance, the teacher can determine: 1) if all students were assigned to a group, 2) which students, if any, did not receive their group notification, and 3) what groups are missing students from the classroom today. To determine if all students were assigned to a group or which students did not need a notification, the CML system specifies that a return receipt be sent back after the students receive notification that they have been placed in a group. To determine which groups are missing students, the teacher can query the[0231]network2 to discover each student's status.
• In a distributed MANET, a negative response (i.e., no return receipt) from a student is not a definitive answer that the student has not received the notification because the student can receive such notification outside of the classroom. For example, if it appears that one Student S did not receive a group notification, this can be because Student S received the notification from another Student Y on the school bus, and neither Student S nor Student Y are currently in the teacher's MANET. Also, in a distributed MANET, a negative response to the teacher's query to determine who is missing in the classroom is not definitive because the[0232]student device12′ of the student may be turned off, and thus unable to respond to the query.
• In each of these cases, although the teacher obtains ambiguous results (that is, a negative response does not necessarily mean that the actual answer to the query is negative), the answer received can be satisfactory because of the nature of the classroom. The teacher can then (a) resend the communication to everyone who has answered in the negative, or (b) contact the appropriate students through other means (such as a face to face discussion) to find out the actual status of the student. In this way the CML system, although not providing unambiguous answers to all possible queries, can provide the teacher with the information needed to act appropriately in the classroom. Similar matters hold for the delivery and receipt of data documents.[0233]
• To participate in a group, a student opens a link to the group manager. This can require a login with a password, and the first time the student logs in, the student may have to create a new password. After linking to the group manager, the student can find out about the group and the role of the student in the group. The student can also determine who are the other members of the group and whether these members are logged in, what are the data objects of the group, and what is the goal or role of the group. If the group is to be a P2P group, the student is also linked to the other members of the group.[0234]
• A primary interaction mode between members of a group is communication. Message data objects mediate communication over the[0235]network2. At one level, thenetwork2 uses an email type system, an instant messenger system, or both systems to implement the communication. Other message types include exchange requests and responses, automated messages such as “You've been added to Group X, whose group manager may be found here” or “A document from your teacher is waiting for you here.” An example of a useful message type is a “dialog,” in which the sender of the message requires a reply. In one embodiment, a dialog is a yes-or-no survey to a request that a particular semantic type of data object be returned.
• A teacher can define an activity as having a certain class of input data object, a certain kind of actor, and, optionally, a certain class of output data objects. The assignment of specific values to the data objects occurs when the activity is instantiated (during run-time operation of the CML system in the network[0236]2). In one embodiment, each activity is defined as having an input data object, a participant actor, and a goal.
• Creating an activity involves identifying each of these items. Specifically, a class of data object and a type of actor (a person, or a group of a particular type defined in its descriptor) are defined, and the goal is textually stated, defined as being a data object of a particular class, or both.[0237]
• Creating a superactivity (i.e., an activity that is composed of a linked collection of activities) also involves identifying the same descriptors as an activity—the input data object, actor, and output data object. As described above, the input data object is the input of the first subactivity, and the output data object is the output of the last subactivity. For a superactivity, the actor is a group if the subactivities are to be performed by multiple actors, otherwise, the actor is just one actor that performs all of the activities.[0238]
• The group associated with the superactivity has each of these actors as members. Accordingly, participants in a lesson can send and receive data objects to and from the actor next and previous (in a linked list) to them in the[0239]network2. For example, the group is created as a limited and directional point-to-point network whose topology reflects the topology of the activity network.
• Besides identifying the group associated with the superactivity, the teacher (or author) identifies the collection of activities and the link topology among the members of the group. The teacher also identifies which member of the superactivity group is to do which activities.[0240]
• The set of participant actors in an activity can be defined as an activity (or interaction) topology with bounded repeats (including properly-nested substructures).[0241]
• FIGS.[0242]5A-5C illustrate an example of a grammar that can be used to describe different classroom and activity topologies. Dotted boxes specify that any item in the box can be repeated. In FIG. 5A is shown an example of an activity topology for a given class activity. In this class activity topology there is oneteacher172, who is linked to one ormore groups176. Eachgroup176 has onerespondent178 and one or moreindividual members180. This grammar shows that this class activity has one or more groups by having the group appear as a dashed-line box, and that eachworkgroup176 has exactly onerespondent178 and one or moreindividual members180 by having theindividual member180 appear, and not the respondent178, in another dashed-line box.
• This grammar generalizes to any activity topology. For example, FIG. 5B shows an activity topology for a classroom activity in which each student ([0243]individual member180′) is to work alone. In FIG. 5B, theteacher172′ is linked to one ormore groups176′ having only oneindividual member180′ (the dashed-line box around theindividual member180′ signifies that there can be more than onegroup176′ and that eachindividual member180′ is a group of one). FIG. 5C shows a classroom activity in whichstudents180″ are to work ingroups176″ of two. As shown, eachgroup176″ has exactly twostudents180″ who can communicate with each other and with theteacher172″.
• Content-Based Routing[0244]
• In the cases described above, the student explicitly chooses a contract to associate with a document for transmissions. In some cases, it is desirable for this step to occur automatically. This automation may be accomplished by submitting a document (and descriptors of the document, if any) to a content-based[0245]routing layer40 described above. Thislayer40 chooses a contract for the document as follows.
• At[0246]step250, a document is submitted to thecontent routing subsystem40. The subsystem finds (step252) all contracts on thedevice12 and then finds (step254) the subset of these contracts that would allow the document to be transmitted. Each contract in this subset is a match. If there are no matches (step256), the document is not forwarded to the next layer in the protocol stack (i.e., the contract layer38). If there is only one match (step258), that contract is associated with the document and passed to thecontract layer38 for transmission (step260). If there is more than one match (step262), the user is presented with a choice among the matches. The selected contract becomes associated with the document.
• Data Migration[0247]
• The[0248]network2 employs a distributed transparent caching subsystem at the datamigration protocol layer54 of eachcomputing device12 for storing data on theMANET 6. In general, the distributed transparent cache provides a mechanism for fine-grained, opportunistic data synchronization along the share pairs by ranking incoming and newly produced data as to their relevance to a particular share pair and importance to an individual (student or teacher).
• FIG. 7A shows one embodiment of this distributed transparent caching subsystem. If the[0249]transmitter T300 sends a communication (hereafter message) over thenetwork2, this message can be received by a plurality ofreceivers R302,302′. Not every receiver (e.g.,receiver302′) may receive this message initially (due to distance factors, such as being out of range, time factors such as thedevice12 not being turned on at that time or not being present that day, etc.). Theline304 from T to R marked with an “X” indicates this undelivered message. In accordance with the principles of the invention, one of theother receivers302,302′ can relay the message to allow all potential receivers to receive the communication. Accordingly, if thereceiver302″ has a contract that is associated with the message, but was unable to receive the message when initially transmitted by thetransmitter300,other receivers302,302′ can forward that message when thereceiver302″ becomes able to receive the message (e.g., thestudent using receiver302″ turns on thestudent device12′ or comes into range of the MANET 6). Note that thereceiver302″ does not need to receive the message within the environment in which thetransmitter300 originally sent the message (e.g., the classroom). Thereceiver302″ can receive the message fromreceiver302′ any time the twostudent devices12′ engage in communication, such as when both students are together riding a school bus.
• Further, receivers (i.e., devices[0250]12) that do not have the appropriate contracts to explicitly send a message can still forward the message. For example, as shown in FIG. 7B, thetransmitter T310 can send a message (associated with a particular share-pair) over thenetwork2 that is received by afirst receiver R312, but not by asecond receiver R314. Thefirst receiver R312 stores the message in cache. In one embodiment, thereceiver R312 does not need to have a contract for this particular share-pair in order to cache this share-pair communication. That is, if there is memory available in the cache of thereceiver302′, and if the message is deemed to have sufficiently high priority, the cache can accept the communication for the purpose of allowingdevices12 that do have the appropriate share-pair contract to query for the communication.
• Consider that these[0251]receivers R312,R314 do not have privileges (i.e., per the share-pair contract) to send a message associated with this particular share-pair. Should thereceivers R312,R314 subsequently become part of a MANET that is inaccessible by thetransmitter T310, the cache ofreceiver R314 can query the cache ofreceiver R312 to see if any messages were sent that are associated with the particular share-pair. (This presumes that thereceiver R314 is interested in this particular share-pair). The cache of thereceiver R312 answers the query in the affirmative and sends the message to the cache ofreceiver R314. Thereceiver R314 then forwards the message to the appropriate application data-delivery system. Because the student who is using thereceiver R312 does not explicitly attempt to send this message, this transmission does not violate the share-pair contract.
• Cache management of share-pair communications is a composite measure 1) of relevance to a device (the recipient of the communication) and 2) of relevance to other classroom participants, particularly participants in the same share-pair. In one embodiment, relevance to a receiving device includes but is not limited to:[0252]
• newness (i.e., generation) of the communication;[0253]
• MIME type of the communication;[0254]
• recency of use of the communication;[0255]
• relevance to the role or roles of the device user (e.g., team leader, content expert);[0256]
• user profile, defined either explicitly or implicitly by behavior;[0257]
• label (e.g., group, topic, who sends it);[0258]
• size of the communication;[0259]
• metadata tagging (and any nested layers of metadata tags) of the communication;[0260]
• Relevance to users of[0261]other devices12 includes but is not limited to:
• recency of requests for specific item;[0262]
• mime type of the communications[0263]
• inferred priority of mime type from share-pair;[0264]
• QOS demand markers associated with share pairs (e.g., team project is very important, or a transient message is not very important). Some share-pairs carry very important content and others do not. QOS demand markers can be reassigned dynamically.[0265]
• how many other share-pairs there are in this set of matched share-pairs; and[0266]
• its examinable contract.[0267]
• This composite cache management is optimized for a distributed network, such as the[0268]MANET 6, in which there is no centralized storage device. Although there is no centralized data storage device, and eachcomputing device12 may have limited memory,other computing devices12 in theMANET 6 may have priorities that ensure that documents that are important to someone in the share-pair are not deleted from the share-pair, but instead are only stored by the individual to whom they are most important.
• In one embodiment, there is a central storage device that can act as a cache of some or all communications in the[0269]network2. This central storage device can store information about all communications that go over theMANET 6, providing not only an additional QOS capability, but also a real-time backup of theentire network2.
• Multicast Packet Hop (Hip Hop)[0270]
• In classroom environments, the networking mechanism for communicating among computing devices[0271]12 (referred to also as nodes12) can be simplified. The use of multicast addresses—corresponding to the share-pair contracts—can accomplish the exchange of information amongnodes12 without using routing tables, without needing to determine actual routes from IP addresses, and without using an IP address to identify a person with a computing device. One such networking mechanism, referred to as multicast packet hop (or “Hip Hop”), enables multi-hop, multicast communications in the wireless network medium without such routing support. In brief overview, eachcomputing device12 that receives an incoming multicast packet decides whether to re-issue that packet to the wireless network medium. One reason for re-issuing the packet is if thecomputing device12 can determine that anothercomputing12 within listening range is interested in the packet and has not yet heard the packet.
• FIG. 8 shows a conceptual diagram of the multicast[0272]packet hop layer50 used by each of thenodes12 in thenetwork2 to propagate packets through thenetwork2. Although a variety of networking mechanisms can be used in service of transporting data, the multicastpacket hop layer50 of the invention is particularly suited to the needs and circumstances associated with a classroom environment. Those needs and circumstances include:
• the participating[0273]nodes12 are typically in close proximity to one another (i.e., under 2 meters to the nearest neighboring node12),
• the classroom environment is relatively isotropic; that is, the environment is approximately the same in every direction in that the number and distribution of neighboring participants is approximately the same for each participant,[0274]
• the number of participants (teacher and students) is typically small and fixed,[0275]
• geographically[0276]proximal nodes12 are likely to be participants working on closely related tasks with significant amounts of common data,
• participating[0277]nodes12 typically have very low processing capabilities,
• participating[0278]nodes12 have stringent power requirements,
• uniform usage of power across the participating[0279]nodes12 is as important as total power consumption,
• the number of participating[0280]nodes12, although variable, has a quite limited range—from a few to a few tens ofnodes12, to, possibly, several hundred, but typically not more, and
• support for node to[0281]node12 communication independent of the data delivery as described herein is of low priority.
• The multicast[0282]packet hop layer50 includeschannel management software324, which provides a short-range (approximately twice the typical inter-node12 distance) wireless networking system (e.g. low transmit power 802.11) capable of carrying IP multicast packets. Components of thechannel management software324, in one embodiment, include achannel query component330, a channelquery response component332, a responseslot selection component334, a packetrepeat decision component336, a repeatslot selection component338, a content packet pass throughcomponent340, and a channel configuration component342.
• The[0283]channel management software324 is in communication with aCML system322, which in one embodiment includes one or more applications written in the ClassSync Modeling Language described above, and with a network stack326. Data flows to and from thewireless network6 through the wireless interface328 and the network stack326. The network stack326 is capable of sending and receiving arbitrary IP multicast packets to and from the wireless interface328. The network stack326 also exchanges data with the channelquery response component332,channel query component330, and the packetrepeat decision component336.
• The packet[0284]repeat decision component336 receives control instructions from the channel configuration component342,channel query component330, and the repeatslot selection component338, sends control instructions to the repeatslot selection component338, and exchanges data communications with the content packet pass throughcomponent340. The content packet pass throughcomponent340 is in communication with theClassSync System322 and operates as a filter of packets passing to and from. Although shown to be part of the multicastpacket hop layer320, the content packet pass throughcomponent340 can be a software component that operates at another layer of theprotocol stack30. For example, in one embodiment, the content packet pass throughcomponent340 operates as thecontract layer38 described in connection with FIG. 1A.
• In one embodiment, a multicast address is associated with a particular data context (e.g., homework). Using data supplied over a different mechanism (e.g., point-to-point beaming, verbal instructions), the channel configuration component[0285]342 configures thosenodes12 that are involved in that particular data context to respond to the multicast address associated with that data context. (In contrast with standard IP multicast, everynode12 in thenetwork2 can source data to a multicast address, and receive data packets addressed to that multicast address.)
• For an activity having one data context only, only one multicast IP address is used in all transmissions and receptions of data. Thus, for each[0286]node12 in thenetwork2, the routing of packets through thenetwork2 reduces to determining, upon receipt of a packet, whether to repeat that packet.
• To make this determination, each[0287]node12 measures the local connectivity of thenetwork2, at configurable intervals, using thechannel query component330. In one embodiment, thechannel query component330 invokes the standard IP multicast ‘interest’ query and records the total number of responses that thenode12 receives. This number, hereafter referred to as the local connectivity number, is used by the packetrepeat decision component336, along with other information, to determine whether a received packet is to be repeated.
• [0288]Other nodes12, upon receiving the query, use the channelquery response component332 and the responseslot selection component334 to appropriately respond to the query. In particular, the channelquery response component332 transmits a response during a time slot determined by the responseslot selection component334 if thenode12 has not received a response from anothernode12 before the node's12 time slot occurs. In one embodiment, the channelquery response component332 invokes the standard IP multicast ‘interest’ channel query response and response slot selection mechanisms.
• In one embodiment, the response[0289]slot selection component334 chooses the time slot randomly upon each occurrence of a request for a time slot from the channelquery response component332. Thus, the amount of time that aparticular node12 waits before responding to a channel query varies from channel query to channel query. This variable delay distributes the power consumed by each of thenodes12 to respond to channel queries—the random delay at eachnode12 causes thenodes12 to take turns transmitting a reply. This distribution of power consumption is particularly advantageous in a classroom where thecomputing devices12 are battery-powered and, with all other factors being equal, reduces that likelihood that somecomputing devices12 will run out power before others in thenetwork2.
• In another embodiment, suitable for classrooms with few students (e.g., 2-30), the response slot is externally assigned—one per[0290]node12 in the classroom, to avoid potential collisions between respondingnodes12. In this embodiment, the external assignment of response slots performs the function of the responseslot selection component334. The externally assigned slots can be periodically rotated among thenodes12 so that no onenode12 bears more of the response burden than anyother node12.
• In another embodiment, suitable for use when the wireless link hardware is so configurable, the response[0291]slot selection component334 includes the contention slot selection mechanism that is part of the wireless Media Access Control (MAC) protocol.
• FIG. 9 shows an embodiment of a process by which a[0292]node12 determines the local connectivity number. Instep344, thechannel query component330 waits for an event to occur. For example, an event can be the arrival of a query response packet (which can be left over from previous query) or a signal from the channel configuration component342 indicating that a recomputation of the local connectivity number is desired (e.g., on the basis of the expiration of a timer). Upon the occurrence of an event, thechannel query component330 determines whether (step346) the event is an incoming query response packet or a signal to begin a new query. If the event is a packet, thenode12 discards (step348) the packet. If the event is a query signal, thechannel query component330 sets (step350) the local connectivity number equal to 0.
• In[0293]step352, thenode12 starts a local timeout timer. Instep354, thechannel query component330 generates and transmits a channel query packet. Thenode12 then counts the number of responses to the channel query packet that occur before the timer times out. Accordingly, thechannel query component330 waits (step356) for the occurrence of an event. Upon the occurrence of an event, thechannel query component330 determines (step358) if the event is the timeout of the timer or the receipt of a packet.
• In[0294]step360, if the event is the timeout of the timer, thechannel query component330 returns the present value of the local connectivity number. Instep362, if the event is a packet, thechannel query component330 determines if the packet is out of date. Thechannel query component330 discards (step364) the packet if the packet is outdated, otherwise, increments (step366) the local connectivity number. Thechannel query component330 then waits (step344) for the occurrence of the next event.
• FIGS.[0295]10A-10E illustrate various examples of computing the local connectivity number inseveral network2 situations. FIG. 10A shows a diagram illustrating an embodiment in which four nodes12 (A, B, C, and D) are within proximity of each other. Eachnode12 has awireless range368 within which thatnode12 can “hear” other nodes12 (i.e., for transmitting and receiving packets). As shown by the overlapping wireless ranges, node12 A can hear node12 B, node12 B can hear nodes12 A and12 C, node12 C can hear nodes12 B and12 D, and node12 D can hear node12 C.
• FIG. 10B shows an example of computing the local connectivity number from the point of view of[0296]node12 B. In this example, node12 B is the queryingnode12 and both nodes12 A and12 C respond to the query of node12 B because both nodes12 A and12 C receive the query and neither node12 A nor node12 C can hear the other. Thus, the local connectivity number is 2.
• FIG. 10C shows an example of computing the local connectivity number in a[0297]network2 with fivenodes12 A,12 B,12 C,12 D, and12 E. In this example, node12 C is the queryingnode12. Because the wireless ranges of nodes12 A,12 B,12 D, and12 E overlap the wireless range of node12 C, eachnode12 receives the query. In thenetwork2, node12 B can also hear nodes12 A and12 D, but notnode12 E. Node12 E can also hear node12 D, but notnodes12 A and12 B. Accordingly, when node12 A responds to the query (in this example, because the node12 A's timer times out before node12 B's timer) node12 B does not reply to the query because node12 B receives node12 A's response before node12 B's timer times out. Similarly, node12 E does not reply to node12 C's query, because node12 E hears node12 D's reply before node12 E's timer times out (in this example, node12 D's timer times out before node12 E's timer). Consequently, node12 C hears two replies, and therefore the local connectivity number from the perspective of node12 C is 2.
• FIG. 10D shows an example of computing the local connectivity number from the point of view of node[0298]12 A. In this example, node12 A is the queryingnode12 and node12 B responds to the query. Node12 C does not respond to the query because node12 C does not hear the query. Node12 C receives node12 B's reply, but discards the reply because the reply, from the perspective of node12 C, is not associated with any known query. Even if node12 C hears the query from node12 A, if node12 B responds first, node12 C does not respond. Thus, the local connectivity number is 1.
• FIG. 10E shows another example of computing the local connectivity number in a[0299]network2 with fournodes12 A,12 B,12 C, and12 D. In this example, node12 B is the queryingnode12. The wireless ranges of nodes12 A,12 C, and12 D overlap the wireless range of node12 B, thus each of these nodes12 A, D and12 D receives the query. In this example, node12 A cannot hear nodes12 C and12 D, node12 C cannot hear nodes12 A and12 D, and node12 D cannot hearnodes12 A and12 C. Accordingly, each of the nodes12 A,12 C, and12 D respond to node12 B, and therefore the local connectivity number from the perspective of node12 B is 3.
• FIG. 11 shows an embodiment of a process by which a[0300]node12 determines whether to reply to a query. Instep370, the channelquery response component332 waits for an event. Upon the occurrence of an event, the channelquery response component332 determines (step372) if the event is the timeout of the timer or the receipt of a packet.
• If the event is a packet, the channel[0301]query response component332 determines (step374) if the packet is a query packet or a response packet.
• If the event is a query packet, the channel[0302]query response component332 requests (step376) a response slot from the responseslot selection component334.
• In[0303]step378, the channelquery response component332 then allocates a time slot and initializes the timer (e.g., timer[query_id]=time[slot], where query_id is a value assigned to identify the query packet, timer[query_id] is the timer associated with the query packet, and time[slot] is the time when thenode12 is to respond to the query packet if thenode12 does not hear another response). The channelquery response component332 then discards (step380) the query packet.
• If the event is a response packet, the channel[0304]query response component332 determines (step382) if a time slot (timer[query_id]) has been allocated. If so, thenode12 has heard a response to a query that thenode12 also heard, but no longer needs to respond to because anothernode12 responded first. Accordingly, the channelquery response component332 deallocates (step384) the time slot and discards (step380) the response packet. If a time slot has not been allocated, thenode12 has heard a response to a query that thenode12 itself has not heard. Accordingly, the channelquery response component332 discards (step380) the response packet.
• If, in[0305]step372, the event is the timeout of the timer, thenode12 has not heard a response to the query from anothernode12. Thus, the channelquery response component332 generates and transmits (step386) a channel query response packet from query_id[timer], deallocates (step388) the timer[query_id], and then waits (step370) for the occurrence of the next event.
• FIGS.[0306]12A-12B show an embodiment of a process by which anode12 determines whether to repeat a received packet. Instep390, the packetrepeat decision component336 waits for an event. Upon the occurrence of an event, the packetrepeat decision component336 determines (step392) if the event is the timeout of the timer or the receipt of a packet.
• If the event is a packet, the packet[0307]repeat decision component336 determines (step394) if the packet is an inbound packet (received from the network2) or an outbound packet (to be transmitted to the network2).
• In general, if the packet is an inbound packet, and not a channel query or a channel query response, the packet[0308]repeat decision component336 determines whether that packet is to be repeated, that is retransmitted (or rebroadcast) over thenetwork2. Instep396, the packetrepeat decision component336 determines if the inbound packet (packet_id) is enqueued, indicating that the packet has been previously received and deemed suitable for retransmission. If the inbound packet is not enqueued, the packetrepeat decision component336 applies (step398) configured filtering criteria to the packet. If the packet does not pass the criteria, the packetrepeat decision component336 discards (step400) the packet. The criteria are based on a context specification currently bound to the multicast address and on the specific metadata associated with the inbound packet.
• For example, situations can arise where a[0309]computing device12 encounters “stray” packets, (e.g., from a neighboring classroom, and it is undesirable to have these stray packets pass through the present classroom into other classrooms. One technique for handling undesired packet traffic is to insure that neighboring classrooms use disjoint sets of multicast IP addresses. For this technique, the criteria used in each of the classrooms are to filtered out packets that have disallowed IP addresses. The technique requires coordination among the classrooms (i.e., the teacher or administrator) to assign the multicast IP addresses to their respective classrooms. Another technique is to include information in the packets that is unlikely to be common between neighboring classrooms. For example, such information can include the name of the teacher and the nature of the class (“Mrs. Brown's Fourth Period Algebra Class”). Accordingly, the packetrepeat decision component336 can be configured to “intelligently” filter undesired packets.
• The application of such criteria is in addition to applying typical IP routing criteria such as the expiration of the time-to-live counter, malformed IP address, corrupt payload, etc. If the inbound packet fails (step[0310]402) any of the additional configured criteria, the packetrepeat decision component336 marks the packet as non-repeating and discards (step400) the packet and any additional received copies.
• If the packet passes the criteria (and other IP routing requirements), the packet[0311]repeat decision component336 requests (step404) a time slot from the repeatslot selection component338 in which to retransmit the packet.
• In one embodiment, the repeat[0312]slot selection component338, the responseslot selection component334 chooses the time slot randomly upon each occurrence of a request for a time slot from the packetrepeat decision component336. Thus, the amount of time that aparticular node12 waits before re-transmitting the multicast packet varies for each multicast packet received. Again, this variable delay distributes the power consumed among thenodes12 in the network.
• In another embodiment, suitable for classes with small numbers of[0313]nodes12, the slot is externally assigned—one pernode12 in the class, thus avoiding potential collisions. Slot assignments can be periodically rotated among thenodes12 so that nonode12 bears more of the response burden, and consumes more battery power, than anyother node12.
• Then in[0314]step406 the packetrepeat decision component336 allocates and initializes the timer[packet_id]=time[slot], the packet[packet_id]=the packet, and the count[packet_id]=1. The packetrepeat decision component336 enqueues (step408) packet_id as pending, discards (step400) the packet, and returns to waiting (step390) for the next occurrence of an event.
• In brief overview, until the timer times out the packet[0315]repeat decision component336 counts the number of copies of the inbound packet (including the original) received by thenode12. If thenode12 has received strictly fewer than the local connectivity number of copies when the timer times out, the packetrepeat decision component336 causes the packet to be transmitted (after first decrementing the counter and performing other normal packet retransmission operations).)
• More specifically, if in[0316]step396 the inbound packet is enqueued (indicating that the packet is waiting to be retransmitted (i.e., pending) or has recently been retransmitted or otherwise handled (i.e., completed)), the packetrepeat decision component336 discards (step410) the inbound packet because there already is an enqueued copy. Instep412, the packetrepeat decision component336 determines if the enqueued packet is pending. If not pending, the packetrepeat decision component336 returns to waiting (step390) for an event.
• If the inbound packet is enqueued as pending, the packet[0317]repeat decision component336 increments (step414) the count for the inbound packet (e.g., packet_id (count[packet_id])). Instep416, the packetrepeat decision component336 compares the current count with the local connectivity number. If the count is less than the local connectivity number, the packetrepeat decision component336 returns to waiting (step390) for an event. If the count equals the local connectivity number, the packetrepeat decision component336 deallocates (step420) packet[packet_id[timer]], the timer[packet_id], and count[packet_id]. Instep422, the packetrepeat decision component336 dequeues the packet_id as pending and enqueues packet_id as completed. Then the packetrepeat decision component336 returns to waiting (step390) for the occurrence of an event.
• If in[0318]step392 the event is the timeout of the timer, the packetrepeat decision component336 generates and transmits (step428) a repeat packet from packet[packet_id[timer]], deallocates, dequeues, enqueues as set forth insteps420 and422, and returns to waiting (step390) for the occurrence of an event.
• If in[0319]step394 the packet is an outbound packet, the packetrepeat decision component336 enqueues (step424) packet_id as completed and transmits (step426) the packet. Then the packetrepeat decision component336 returns to waiting (step390) for the occurrence of an event.
• The networking mechanism described in FIGS.[0320]8-12B includes two properties that help battery life. A first property, packets take short hops, and short distances between hops require less transmission power than longer distances. A second property, power consumption is distributed among thenodes12 by causing thenodes12, in effect, to take turns when responding to channel queries and when re-transmitting multicast packets.
• The present invention may be implemented as one or more computer-readable software programs embodied on or in one or more articles of manufacture. The article of manufacture can be, for example, any one or combination of a floppy disk, a hard disk, hard-disk drive, a CD-ROM, a DVD-ROM, a flash memory card, an EEPROM, an EPROM, a PROM, a RAM, a ROM, or a magnetic tape. In general, any standard or proprietary, programming or interpretive language can be used to produce the computer-readable software programs. Examples of such languages include C, C++, Pascal, JAVA, BASIC, Visual Basic, and Visual C++. The software programs may be stored on or in one or more articles of manufacture as source code, object code, interpretive code, or executable code.[0321]
• While the invention has been shown and described with reference to specific preferred embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the following claims.[0322]

Claims (86)

What is claimed is:

1. A method for use by a first computing device to transmit information to at least one other computing device over a network communication medium according to a protocol stack having a plurality of protocol layers, the method comprising:

determining at a particular protocol layer whether to transmit information over the network communication medium based on at least one term of a contract associated with the information; and

upon determining to present the information to the network communication medium, forwarding the information to a lower protocol layer in the protocol stack for transmission over the communication medium.

2. The method ofclaim 1 further comprising associating an identifier with the information by which identifier the contract is associated with the information.

3. The method ofclaim 1 further comprising associating an identifier with the information and including that identifier in the information before transmitting the information over the network communication medium.

4. The method ofclaim 1 further comprising receiving the information at the particular protocol layer from a higher protocol layer in the protocol stack.

5. The method ofclaim 1 further comprising receiving the contract from another computing device over the network communication medium.

6. The method ofclaim 5 wherein the step of receiving the contract occurs using one of IR (infrared) beaming, RF (radio frequency) communication, and wired communication.

7. The method ofclaim 1 further comprising transmitting the contract over the network communication medium to another computing device.

8. The method ofclaim 1 further comprising receiving the contract over a secure communication channel.

9. The method ofclaim 1 further comprising storing the contract on the first computing device.

10. The method ofclaim 1 further comprising storing a plurality of contracts on the first computing device.

11. The method ofclaim 10 wherein the stored contracts are unmodifiable by any program other than a program that handles the particular protocol layer.

12. The method ofclaim 1 wherein the contract specifies one or more terms that the information must satisfy in order to be transmitted over the network communication medium.

13. The method ofclaim 1 wherein the contract specifies one or more terms that determine which actions, if any, can be performed on the information by a computing device receiving the information.

14. The method ofclaim 1 wherein the contract specifies at least one term comprising a parameter selected from a temporal parameter, an information-type parameter, an information-length parameter, and an information-content parameter.

15. The method ofclaim 1 further comprising encrypting the information before transmitting the information over the network communication medium.

16. The method ofclaim 1 further comprising transmitting the contract to each computing device used by a user belonging to a user group.

17. The method ofclaim 1 further comprising allowing the user of a computing device that receives the contract to transmit a copy of the contract to the user of another computing device.

18. The method ofclaim 1 further comprising providing the contract to a plurality of computing devices, wherein the contract permits one of the computing devices having the contract to transmit information associated with the contract and another of the computing devices having the contract to receive information associated with the contract.

19. The method ofclaim 1 further comprising providing the contract to a plurality of computing devices, wherein the contract permits each computing device having the contract to transmit and to receive information associated with the contract.

20. The method ofclaim 1 further comprising providing a user interface by which a user of the first computing device associates the contract with the information.

21. The method ofclaim 1 further comprising choosing the contract for association with the information based on a content of the information.

22. The method ofclaim 1 further comprising choosing the contract for association with the information based on an application program executing on the first computing device.

23. The method ofclaim 1 further comprising choosing the contract for association with the information based on a temporal context of the first computing device.

24. A method for use by a first computing device to receive information from at least one other computing device over a network communication medium according to a protocol stack having a plurality of protocol layers, the method comprising:

identifying at a particular protocol layer of a protocol stack a contract associated with information received over the network communication medium; and

determining at the particular protocol layer whether to present the information to a higher layer in the protocol stack based on at least one term of the contract.

25. The method ofclaim 24 further comprising extracting from the information an identifier that is associated with the contract.

26. The method ofclaim 24 wherein the step of determining whether to present the information to the higher layer in the protocol stack includes determining whether the first computing device has a copy the contract.

27. The method ofclaim 24 further comprising receiving the contract from another computing device over the communication medium.

28. The method ofclaim 27 wherein the step of receiving the contract occurs using one of IR (infrared) beaming, RF (radio frequency) communication, and wired communication.

29. The method ofclaim 24 further comprising receiving the contract over a secure communication channel.

30. The method ofclaim 24 further comprising storing the contract on the first computing device.

31. The method ofclaim 24 further comprising storing a plurality of contracts on the first computing device.

32. The method ofclaim 31 wherein the stored contracts are unmodifiable by any program other than a program that handles the particular protocol layer.

33. The method ofclaim 24 further comprising specifying one or more terms in the contract that the information must satisfy to be presented to the higher protocol layer of the protocol stack.

34. The method ofclaim 24 wherein the contract specifies at least one term comprising a parameter selected from a temporal parameter, an information-type parameter, an information-length parameter, and an information-content parameter.

35. The method ofclaim 24 further comprising decrypting the information before presenting the information to the higher protocol layer of the protocol stack.

36. The method ofclaim 24 further comprising receiving the contract to become a member of a user group.

37. The method ofclaim 24 further comprising allowing the user of the first computing device to transmit a copy of the contract to the user of another computing device.

38. The method ofclaim 24 further comprising providing the contract to a plurality of computing devices, wherein the contract permits one of the computing devices having the contract to transmit information associated with the contract and another of the computing devices having the contract to receive information associated with the contract.

39. The method ofclaim 24 further comprising providing the contract to a plurality of computing devices, wherein the contract permits each computing device having the contract to transmit and to receive information associated with the contract.

40. The method ofclaim 24 further comprising:

entering by the first computing device a secure mode of operation in response to the information received over the network communication medium;

issuing a reply indicating that the first computing device has entered the secure mode of operation;

activating an indicator on the first computing device that verifiably shows that the first computing device is operating in the secure mode of operation.

41. The method ofclaim 40 further comprising receiving the information over the network communication medium from a security station.

42. The method ofclaim 40 wherein the security station is a wireless access point [controlled by a server system].

43. The method ofclaim 40 wherein the security station includes an infrared beaming port.

44. The method ofclaim 40 further comprising placing the security station where a user of the first computing device entering a restricted zone necessarily passes near the security station.

45. The method ofclaim 40 wherein activating the indicator includes at least one of (i) affixing a sticker to a visible surface of the first computing device, (ii) causing the first computing device to produce a detectable output, and (iii) enabling the first computing device to respond correctly to a challenge.

46. The method ofclaim 45 wherein the detectable output is at least one of an illuminated LED (light emitting diode), an emitted sound, and a wireless transmission that indicates the first computing device is operating in the secure mode.

47. The method ofclaim 45, wherein the challenge includes providing a predefined input to the first computing device.

48. The method ofclaim 45 wherein the challenge includes pressing one or more particular keys on a keyboard of the first computing device.

49. The method ofclaim 40, wherein entering the secure mode of operation includes prohibiting the first computing device from at least one of (i) communicating over a particular physical link, (ii) launching an application program, (iii) storing data in memory, (iv) reading data from memory, (v) installing software, (vi) communicating with hardware, (vii) accessing a particular system library, (viii) performing a start-up type of action, and (ix) placing a restriction on a specific application program.

50. The method ofclaim 40, further comprising maintaining a session on the first computing device across a start-up type of event.

51. The method ofclaim 40, wherein the reply includes at least one of (i) a certificate of authenticity, (ii) a certificate of integrity, (iii) a version number, and (iv) a characteristic of the computing device.

52. The method ofclaim 40, further comprising receiving a challenge over the wireless network medium and computing a response that demonstrates the authenticity and integrity of the first computing device.

53. The method ofclaim 40, further comprising placing the first computing device in the secure mode of operation for a predefined duration.

54. The method ofclaim 53 wherein placing the first computing device includes transmitting a contract to the first computing device.

55. The method ofclaim 24 further comprising:

entering a secure session by the first computing device for a defined duration;

specifying a contract to supercede all other contracts presently on the first computing device for the duration of the secure session; and

marking the first computing device to show that the first computing device is in the secure session and is operating under the specified contract.

56. The method ofclaim 55 further comprising filtering, by the contract that supercedes all other contracts, all communications generated by the first computing device for transmission.

57. An article of manufacture having computer-readable program means embodied thereon for communicating over a network communication medium, the article of manufacture comprising:

computer-readable program means for determining at a particular protocol layer of a protocol stack that a message is associated with a contract; and

computer-readable program means for accessing the contract at the particular protocol layer to determine from at least one term of the contract whether to forward the message from the particular protocol layer.

58. The article of manufacture ofclaim 57 further comprising computer-readable program means for receiving the contract from a computing device over the network communication medium.

59. The article of manufacture ofclaim 57 further comprising computer-readable program means for transmitting the contract over the network communication medium to a computing device.

60. The article of manufacture ofclaim 57 further comprising computer-readable program means for storing the contract on a computing device.

61. The article of manufacture ofclaim 57 further comprising computer-readable program means for storing a plurality of contracts on a computing device.

62. The article of manufacture ofclaim 61 wherein the stored contracts are unmodifiable by any program other than a program that handles the particular protocol layer.

63. The article of manufacture ofclaim 57 wherein the contract specifies one or more terms that the message must satisfy to be forwarded from the particular protocol layer.

64. The article of manufacture ofclaim 57 wherein the contract specifies at least one term comprising a parameter selected from a temporal parameter, an information-type parameter, an information-length parameter, and an information-content parameter.

65. The article of manufacture ofclaim 57 further comprising computer-readable program means for encrypting the message before placing the message on the network communication medium.

66. The article of manufacture ofclaim 57 further comprising computer-readable program means for transmitting the contract to each computing device used by a user belonging to a user group.

67. The article of manufacture ofclaim 57 further comprising computer-readable program means for allowing the user of a computing device that receives the contract to transmit a copy of the contract to the user of another computing device.

68. The article of manufacture ofclaim 57 further comprising computer-readable program means for providing the contract to a plurality of computing devices, wherein the contract permits one of the computing devices having the contract to transmit information associated with the contract and another of the computing devices having the contract to receive messages associated with the contract.

69. The article of manufacture ofclaim 57 further comprising computer-readable program means for providing the contract to a plurality of computing devices, wherein the contract permits each computing device having the contract to transmit and to receive messages associated with the contract.

70. The article of manufacture ofclaim 57 further comprising computer-readable program means for providing a user interface by which a user of a computing device associates the contract with the message.

71. The article of manufacture ofclaim 57 further comprising computer-readable program means for selecting the contract for association with the message based on a content of the message.

72. The article of manufacture ofclaim 57 further comprising computer-readable program means for selecting the contract for association with the message based on an application program executing on a computing device.

73. The article of manufacture ofclaim 57 further comprising computer-readable program means for selecting the contract for association with the message based on a temporal context of a computing device.

74. A method for providing a computing device with a capability to perform an interaction with a resource in a wireless network, the method comprising;

transmitting a first message from the first computing device to the second computing device to initiate an exchange for obtaining the capability;

receiving at the first computing device a response to the first message indicating a type of interaction that is supported by the second computing device; and

transmitting from the first computing device to the second computing device a second message including a contract corresponding to the type of interaction to provide the second computing device with the capability to perform the interaction.

75. The method ofclaim 74, wherein the transmitting of the first message occurs when a predefined key of the first computing device is pressed.

76. The method ofclaim 74, wherein the transmitting of the first message occurs through an infrared transceiver of the first computing device.

77. The method ofclaim 74, wherein the transmitting of the first message includes transmitting type information representing content in the first message.

78. The method ofclaim 74, wherein the transmitting of the first message is a point-to-point transmission directed to a specific transceiver on the second computing device that is dedicated to respond to the first message.

79. The method ofclaim 74, further comprising transmitting the contract to the resource in the network to enable interaction between the resource and any computing device having the contract.

80. A method for providing a capability to perform an interaction with a resource in a wireless network including a first and second computing devices, the method comprising:

receiving at the second computing device a first message to initiate a capability exchange with the first computing device;

transmitting by the second computing device a response to the first message to the first computing device indicating a type of interaction that is supported by the second computing device; and

receiving at the second computing device a second message including a contract corresponding to the type of interaction to provide the second computing device with the capability to perform the interaction.

81. The method of claim80, wherein the receiving of the first message occurs through an infrared transceiver of the second computing device.

82. The method of claim80, wherein the receiving of the first message includes receiving type information representing content in the first message.

83. The method of claim80, wherein the receiving of the first message is a point-to-point communication directed to a specific transceiver on the second computing device that is dedicated to respond to the first message.

84. A method of controlling access to an electronic resource, the method comprising the steps of:

providing to the electronic resource a contract having an identifier; and

processing by the electronic resource any communication received by the electronic resource that has the identifier of the contract, otherwise filtering out such communication from further processing.

85. The method of claim84, wherein the contract specifies one or more conditions for using the electronic resource, and further comprising processing by the electronic resource a received communication if that communication satisfies each condition specified by the contract, otherwise filtering out such communication from further processing.

86. The method of claim84 further comprising providing the identifier of the contract to a computing device for inclusion in communications sent by the computing device to the electronic resource to enable the computing device to use the electronic resource.

Images