Abstract:
The invention is a mobile device collaboration framework (MDCF)—a form of communications framework, which enables devices to discover other devices that support the framework, access applications and services on those devices and exchange a variety of media and application-specific data. It is not tied to any one communications medium or protocol. It supports access restriction and data security at many levels. Sessions can involve multiple devices, creating subnets of devices, each with a shared purpose or task.

Description:
RELATED APPLICATION 
     This application claims the benefit of U.S. Provisional Application No. 61/749,138, filed on Jan. 4, 2013. The teachings of that application are incorporated herein in its entirety. 
    
    
     BACKGROUND OF THE INVENTION 
     Mobile computing devices, such as notebook PC&#39;s, smart phones, and tablet computing devices, are now common tools used for producing, analyzing, communicating, and consuming data in both business and personal life. Consumers continue to embrace a mobile digital lifestyle as the ease of access to digital information increases with high-speed wireless communications technologies becoming ubiquitous. Popular uses of mobile computing devices include displaying large amounts of high-resolution computer graphics information and video content, often wirelessly streamed to the device. While these devices typically include a display screen, the preferred visual experience of a high-resolution, large format display cannot be easily replicated in such mobile devices because the physical size of such device is limited to promote mobility. Another drawback of the aforementioned device types is that the user interface is hands-dependent, typically requiring a user to enter data or make selections using a keyboard (physical or virtual) or touch-screen display. As a result, consumers are now seeking a hands-free high-quality, portable, color display solution to augment or replace their hands-dependent mobile devices. 
     SUMMARY OF THE INVENTION 
     Recently developed micro-displays can provide large-format, high-resolution color pictures and streaming video in a very small form factor. One application for such displays can be integrated into a wireless headset computer worn on the head of the user with a display within the field of view of the user, similar in format to either eyeglasses, audio headset or video eyewear. A “wireless computing headset” device includes one or more small high-resolution micro-displays and optics to magnify the image. The WVGA microdisplays can provide super video graphics array (SVGA) (800×600) resolution or extended graphic arrays (XGA) (1024×768) or even higher resolutions. A wireless computing headset contains one or more wireless computing and communication interfaces, enabling data and streaming video capability, and provides greater convenience and mobility through hands dependent devices. For more information concerning such devices, see co-pending patent applications entitled “Mobile Wireless Display Software Platform for Controlling Other Systems and Devices,” U.S. application Ser. No. 12/348,648 filed Jan. 5, 2009, “Handheld Wireless Display Devices Having High Resolution Display Suitable For Use as a Mobile Internet Device,” PCT International Application No. PCT/US09/38601 filed Mar. 27, 2009, and “Improved Headset Computer,” U.S. application Ser. No. 61/638,419 filed Apr. 25, 2012, each of which are incorporated herein by reference in their entirety. 
     Embodiments provide a framework that enables communications, control and data transfer between devices running the services. Embodiments allow context driven interaction between devices. 
     In a preferred embodiment the invention is a method of networking digital processing devices comprising (a) using a collaboration services module executed by a processor, detecting one or more devices within range, determining a factor in common amongst the detected devices in range of the processor, requesting the detected device to interact, and upon acceptance by the detected device, interacting the processor and the detected device, resulting in a network including the processor and the detected device; and (b) configuring the network to interact the processor and the detected device as a function of determined factor in common. In other embodiments the method is that described above in this paragraph (a) wherein the processor is a headset computer; (b) wherein the processor is a headset computer, and the factor in common is an activity identifier and the network is configured by determining applications, programs, services, and functions on the detected device that are shareable with and useable by the headset computer; (c) wherein the interacting enables communications, control and data transfer between the processor and the detected device; (d) wherein the interacting in configuring the network is context driven; (e) wherein the interacting between the processor and the detected device is over a wireless transport; (f) wherein the interacting between the processor and the detected device is over a wireless transport, and the wireless transport is any of BlueTooth, WiFi or other protocol; (g) wherein the network is formed of multiple detected devices and the processor; and (h) wherein the network is formed of multiple detected devices and the processor, and the multiple detected devices are headset computers. 
     In a preferred embodiment the invention is a computer apparatus networking digital processing devices comprising (a) a collaboration services module executed by a processor, the collaboration services module detecting one or more devices within range, determining a factor in common amongst the detected devices in range of the processor, and requesting the detected device to interact; and upon acceptance by the detected device, interacting the processor and the detected device, resulting in a network including the processor and the detected device; and (b) a device collaboration framework configuring the network to interact the processor and the detected device as a function of determined factor in common. In other embodiments the computer apparatus is that described above in this paragraph (a) wherein the processor is a headset computer; (b) wherein the processor is a headset computer and the factor in common is an activity identifier and the network is configured by determining applications, programs, services and functions on the detected device that are shareable with and useable by the headset computer; (c) wherein the interacting enables communications, control and data transfer between the processor and the detected device; (d) wherein the processor is a headset computer; (e) wherein the device collaborative framework configures the network in a context driven manner; (f) wherein network is formed of multiple detected devices and the processor; and (g) wherein network is formed of multiple detected devices and the processor and the multiple detected devices are headset computers. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention. 
         FIG. 1A  is a schematic illustrations of a headset computer cooperating with a host computer (e.g., Smart Phone, laptop, etc.) according to principles of the present invention. 
         FIG. 1B  is a schematic illustration of a headset computer according to aspects of the present invention. 
         FIG. 2  is a block diagram of flow of data and control in the embodiments of  FIGS. 1A and 1B . 
         FIG. 3  is a flow diagram of collaboration services in embodiments of the present invention. 
         FIG. 4  is a diagram of ad hoc communications networks and subnetworks being formed among headset computers worn by responders to an incident. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIGS. 1A and 1B  show an example embodiment of a wireless computing headset device  100  (also referred to herein as a headset computer (HSC)) that incorporates a high-resolution (VGA or better) microdisplay element  1010 , collaboration services (ad hoc network engine or agent)  3000  (shown in  FIG. 3 ), and other features described below. HSC  100  can include audio input and/or output devices, including one or more microphones, input and output speakers, geo-positional sensors (GPS), three to nine axis degrees of freedom orientation sensors, atmospheric sensors, health condition sensors, digital compass, pressure sensors, environmental sensors, energy sensors, acceleration sensors, position, attitude, motion, velocity and/or optical sensors, cameras (visible light, infrared, etc.), multiple wireless radios, auxiliary lighting, rangefinders, or the like and/or an array of sensors embedded and/or integrated into the headset and/or attached to the device via one or more peripheral ports  1020  (shown in  FIG. 1B ). Typically located within the housing of headset computing device  100  are various electronic circuits including, a microcomputer (single or multicore processors), one or more wired and/or wireless communications interfaces, memory or storage devices, various sensors and a peripheral mount or mount, such as a “hot shoe”  1020 . 
     Example embodiments of the HSC  100  can receive user input through sensing voice commands, head movements,  110 ,  111 ,  112  and hand gestures  113 , or any combination thereof. Microphone(s) operatively coupled or preferably integrated into the HSC  100  can be used to capture speech commands which are then digitized and processed using automatic speech recognition techniques. Gyroscopes, accelerometers, and other micro-electromechanical system sensors can be integrated into the HSC  100  and used to track the user&#39;s head movement to provide user input commands. Cameras or other motion tracking sensors can be used to monitor a user&#39;s hand gestures for user input commands. Such a user interface overcomes the hands-dependent formats of other mobile devices. 
     The headset computing device  100  can be used in various ways. It can be used as a remote display for streaming video signals received from a remote host computing device  200  (shown in  FIG. 1A ). The host  200  may be, for example, a notebook PC, smart phone, tablet device, or other computing device having less or greater computational complexity than the wireless computing headset device  100 , such as cloud-based network resources. The headset computing device  100  and host  200  can wirelessly communicate via one or more wireless protocols, such as Bluetooth®, Wi-Fi, WiMAX, 4G LTE or other wireless radio link  150 . (Bluetooth is a registered trademark of Bluetooth Sig, Inc. of 5209 Lake Washington Boulevard, Kirkland, Wash. 98033.) In an example embodiment, the host  200  may be further connected to other networks, such as through a wireless connection to the Internet or other cloud-based network resources, so that the host  200  can act as a wireless relay. Alternatively, some example embodiments of the HSC  100  can wirelessly connect to the Internet and cloud-based network resources without the use of a host wireless relay. 
       FIG. 1B  is a perspective view showing some details of an example embodiment of a headset computer  100 . The example embodiment HSC  100  generally includes, a frame  1000 , strap  1002 , rear housing  1004 , speaker  1006 , cantilever, or alternatively referred to as an arm or boom  1008  with a built in microphone, and a micro-display subassembly  1010 . 
     A head worn frame  1000  and strap  1002  are generally configured so that a user can wear the headset computer device  100  on the user&#39;s head. A housing  1004  is generally a low profile unit which houses the electronics, such as the microprocessor, memory or other storage device, along with other associated circuitry. Speakers  1006  provide audio output to the user so that the user can hear information. Microdisplay subassembly  1010  is used to render visual information to the user. It is coupled to the arm  1008 . The arm  1008  generally provides physical support such that the microdisplay subassembly is able to be positioned within the user&#39;s field of view  300  ( FIG. 1A ), preferably in front of the eye of the user or within its peripheral vision preferably slightly below or above the eye. Arm  1008  also provides the electrical or optical connections between the microdisplay subassembly  1010  and the control circuitry housed within housing unit  1004 . 
     According to aspects that will be explained in more detail below, the HSC display device  100  allows a user to select a field of view  300  within a much larger area defined by a virtual display  400 . The user can typically control the position, extent (e.g., X-Y or 3D range), and/or magnification of the field of view  300 . 
     While what is shown in  FIGS. 1A and 1B  is a monocular microdisplay presenting a single fixed display element supported on the face of the user with a cantilevered boom, it should be understood that other mechanical configurations for the remote control display device  100  are possible. 
       FIG. 2  is a block diagram showing more detail of the HSC device  100 , host  200  and the data that travels between them. The HSC device  100  receives vocal input from the user via the microphone, hand movements or body gestures via positional and orientation sensors, the camera or optical sensor(s), and head movement inputs via the head tracking circuitry such as 3 axis to 9 axis degrees of freedom orientational sensing. These are translated by software in the HSC device  100  into keyboard and/or mouse commands that are then sent over the Bluetooth or other wireless interface  150  to the host  200 . The host  200  then interprets these translated commands in accordance with its own operating system/application software to perform various functions. Among the commands is one to select a field of view  300  within the virtual display  400  and return that selected screen data to the HSC device  100 . Thus, it should be understood that a very large format virtual display area might be associated with application software or an operating system running on the host  200 . However, only a portion of that large virtual display area  400  within the field of view  300  is returned to and actually displayed by the micro display  1010  of HSC device  100 . 
     A Headset Computer (HSC)  100  in embodiments runs collaboration services (an ad hoc networking engine or agent)  3000 , detailed in  FIG. 3  below. 
     In one embodiment the HSC  100  may take the form of the HSC described in a co-pending U.S. Patent Publication Number 2011/0187640 which is hereby incorporated by reference in its entirety. 
     In another embodiment, the invention relates to the concept of using a Head Mounted Display (HMD)  1010  in conjunction with an external ‘smart’ device  200  (such as a smartphone or tablet) to provide information and control to the user hands-free. The invention requires transmission of small amounts of data, providing a more reliable data transfer method running in real-time. 
     In this sense therefore, the amount of data to be transmitted over the connection  150  is small—simply instructions on how to lay out a screen, which text to display, and other stylistic information such as drawing arrows, or the background colors, images to include, etc. 
     Additional data could be streamed over the same  150  or another connection and displayed on screen  1010 , such as a video stream if required by the Controller  200 . 
     The collaboration framework is a service  3000  that runs on multiple devices such as mobile devices, computer systems such as laptops and desktops and other devices. In embodiments, the collaboration service  3000  runs on multiple HSCs  100  and hosts  200 . 
     There are two main functions of the framework  3000 . The first relates to connection of devices, such as  100 ,  200  described above in  FIGS. 1A, 1B, and 2 . Using a series of announcements and discoveries, the framework develops and maintains a real-time list of devices that are ‘in range’ (accessible on a common network infrastructure e.g., a subnet) and that are running the same collaboration service  3000 . The collaboration services  3000  enable devices  100 ,  200  to detect the functionality available on other devices  100 ,  200  such as video conferencing capabilities, or specific software that is available. There may also be customizable permission levels and security. 
     In this context, devices  100 ,  200  being ‘in range’ of each other means accessible by any communications medium and protocol available to the device, subject to necessary communications support software being installed. The information exchanged in this discovery process includes details of the applications and services available on each device. Examples could include video conferencing capabilities, or specific applications related to a specific activity. All information exchanged can be limited by a multi-level access control mechanism that covers the activity concerned as well as the user, their role, device, group, organization and location. 
     The second function of the collaboration services framework relates to device  100 ,  200  interaction. For example, a device might see that another device has a camera and video chat software, and then can send out a request to start a video chat session. The other device can accept or reject this request. 
     Restated, the second function of the framework  3000  relates to use of the applications and services enumerated by the discovery process. The framework/collaboration services  3000  enable one device to request actions by other devices it has discovered. Possible examples include instigating an audio-video call with the user of another device, accessing data from a sensor attached to another device, and sharing a document. The framework does not limit or specify the applications and services that could be created to make use of it. 
     The chief advantage to the user is that the framework/collaboration services  3000  handle all of the connection details such as working out device IP addresses, security, etc. Based on the position of the user in that specific framework context (user role, etc.), the user can easily interact with other devices or users, gaining information in a controlled way. 
       FIG. 3  is a flowchart illustrative of implementation by Host  200  and HSC  100  executing collaboration services  3000 . 
     The collaboration services module  3000  running on host  200  and/or HSC  100  first detects other devices  100 ,  200  within range (step  309 ). If a device is detected to be within range then step  310  determines available capability of the detected device. This includes determining program applications and permissions thereof on the detected device. After the determination at step  310 , the collaboration services module  3000  prepares and transmits a request  315  for device interaction (for interaction with the detected device). Upon the detected device responding in the positive to the request of  315 , the collaboration services step  320  enables and provides interaction between the detected device and Host  200  or HSC  100  executing the collaboration services  3000 . 
       FIG. 4  provides an example of ad hoc networks according to the present invention being used to facilitate communication among teams and team members wearing HSCs  100 . An ambulance  410  arrives at a large incident  400  where there are three victims  403   a ,  403   b ,  403   c  and members of the public (not shown) are watching out of curiosity. On scene are a medical team  420 , comprising a consultant  421  and three paramedics  422   a ,  422   b ,  422   c ; a police team  430 , comprising a sergeant  431  and two police officers  432   a ,  432   b ; and a repair team  440 , comprising a foreman  441  and two road crewmen,  442   a ,  442   b.    
     At incident  400 , each of the teams  420 ,  430 ,  440  is responsible for a primary activity. The medical team  420  is responsible for performing medical activities, including managing the care of the victims  403   a ,  403   c ,  403   c , medically assessing the victims, helping the victims, accessing records, sending diagnostic data, and stabilizing the victims for transport. The police team  430  is responsible for performing investigation activities (not shown), such as securing the scene, talking to witnesses, accessing vehicle records, conducting an investigation, and providing traffic control. The repair team  440  is responsible for performing repair activities (not shown), including repairing damaged road equipment, property, buildings, material, phone poles, and other infrastructure. 
     Coordination of activities among the teams is important. For example, the repair team  440  needs to liaise with the police team  430  and medical team  420  to effect the repairs. Accordingly, the teams are collectively responsible for coordination activities, in addition to their primary activities, to ensure the teams work together and don&#39;t interfere with the others&#39; work. This responsibility is vested in a coordination team  450  comprising the medical consultant  421 , police sergeant  431 , and crew boss  441 . 
     Communication, data sharing, and other functions within and among these teams  420 ,  430 ,  440 ,  450  is essential to the teams&#39; being able to perform their medical activities, police activities, repair activities, and coordination activities. This communication is provided according to aspects of the present invention, wherein members of the teams  420 ,  430 ,  440 ,  450  wear headset computers HSC  100  and these headset computers associate with each other in ad hoc networks. 
     Network connectivity may be provided by the ambulance  410  that hosts a wide area Wi-fi network and/or individual ones (Wi-fi networks) of HSCs  100 . Connected to the Wi-fi network are the sergeant  431 , two police officers  432   a ,  432   b , medical consultant  421 , three paramedics  422   a ,  422   b ,  422   c , repair crew foreman  441 , and two road crewmen,  442   a ,  442   b.    
     The ad hoc networks are organized with consideration given to the classes of activities being performed at site  400 : medical, police, repair, and coordination. Accordingly, 4 MDCF (mobile device collaboration framework) activity networks, all subsets of the overall MDCF network, are established to link the headsets HSC  100  of users that are involved in those activities. Each MDCF network is in turn a subset of the Wi-fi network. In this manner, headsets HSC  100  worn by members of medical team  420  are linked via MDCF  425 ; headsets HSC  100  worn by members of police team  430  are linked via MDCF  435 ; headsets HSC  100  worn by members of repair team  440  are linked via MDCF  445 ; and headsets HSC  100  worn by members  421 ,  431 ,  441  of coordination team  450  are linked via MDCF  455 . 
     Members&#39; headset computers have processors running collaboration services modules  3000 . These modules detect whether certain other devices are in range. The modules can also detect other aspects of other users&#39; devices that can allow for selective, intelligent, or secure formation of networks and subnetworks, based on a variety of factors. These factors could include physical proximity of two devices as determined, for example, by GPS positioning data. Another factor could be unique identifiers associated with headset computers worn by members of, for example, the police team  430  to identify the headsets as police team headsets  100 , and a different identifier is associated with the medical team HSCs  100 . 
     For example, HSC  100  worn by police sergeant  431  has a collaboration services module  3000  executed by a processor. The module detects that policemen  432   a  and  432   b  are within communications range, and are further within a certain physical proximity as determined by GPS data. The module  3000  also determines that policemens&#39;  432   a  and  432   b  headsets HSC  100  share a common (police) identifier with that of the sergeant. Based on physical proximity, commonality of identifier, or both, HSC  100 s of sergeant  431  and policemen  432   a  and  432   b  are associated in a subnet, such as MDCF  435 , by the request-accept process of  FIG. 3 . 
     Within the subnet MDCF module  3000  enables each involved headset  100  to discover applications, features, functions/capabilities on the other headsets  100  of the subnetwork  435 . With the results of this discovery, each headset  100  in subnetwork MDCF  435  has a means of sharing the applications, programs, features and functions of the subnetwork as if loaded directly on the headset. Consequently, each HSC  100  of a team  430  does not need to necessarily be configured with the same programs, functionality, etc., knowing that sharing of such is made available by subnetwork  435  communications. 
     Likewise, HSC  100  worn by medical director  421  executes collaboration services module  3000 . The module detects that paramedics  422   a,b,c  headsets  100  are within range and share a common (medical team) identifier with medical director  421 &#39;s HSC  100 . Based on these factors, HSCs  100  of medical director  421  and paramedics  422   a,b,c  are associated in subnetwork MDCF  425 . Within the subnetwork  425 , module  3000  enables each involved headset  100  to discover and share applications, programs, features, functions, etc. on the other headsets of subnetwork  425 . 
     Similarly, HSC  100  worn by crew foreman  441  executes collaboration services  3000 . The module detects that road crewmen&#39;s  442   a,b &#39;s headsets  100  are within range and share a common (repair crew) identifier with crew foreman  441 &#39;s HSC  100 . Based on these factors, HSCs  100  of crew boss  441  and road crewmen  442   a,b  are associated in subnetwork MDCF  445 . Within the subnetwork  445 , module  3000  enables each involved headset  100  to discover and share applications, programs, features, functions, etc. on the other headsets of subnetwork  445 . 
     The module in HSC  100  of the police sergeant  431  determines that other devices are within range, such as for example, that of medical director  421 . Further, based on commonality of an identifier in HSC  100  (the sergeant  431  and the medical director  421  both being members of the coordination team  450 , for example), the module  3000  joins the police sergeant and medical director in a subnet such as collaboration network MDCF  455 . Where HSC  100  of the medical director  421  and police sergeant  431  do not share a common identifier, module  3000  does not discover and share applications, functions, etc. as in subnet  435  but rather allows certain communications and cooperation defined for this subnetwork  455 . The module  3000  keeps track of devices as they go in and out of range, as personnel arrive and depart from the scene  400 . 
     Note that the medical consultant  421 , the police sergeant  431 , and the repair crew boss  441  are each part of two MDCF activity networks, corresponding to their area of operations and overall coordination. 
     Each of the separate MDCF activity networks  425 ,  435 ,  445 ,  455  provides a number of features to the members, including targeted, secure communications, activity-specific applications, session (incident) management, and protection from deliberate or inadvertent interference and snooping. Some of the applications and programs on the medical director&#39;s HSC  100  are not loaded on the HSCs  100  of the police team  430  or repair team  440 . Likewise, some of the applications, programs and communications frequencies, etc. on the police team&#39;s HSCs  100  are not on the medical teams  420 &#39;s or repair team  400 &#39;s HSCs  100 ; and similarly, for programs, features, etc. of the HSCs  100  of the repair team  440  as compared to HSCs  100  of the medical team  420  and police team  430 . MDCF  3000  also supports the use of multiple concurrent communication interfaces and enhanced networking capabilities such as mesh networking. For example, the medical team  420  could use mesh networking to optimize communications among them as they roam the scene of the incident. 
     Importantly, a device  100  of a member of one team  420 ,  430 ,  440 ,  450  in a respective MDCF activity network  425 ,  435 ,  445 ,  455  may advantageously use program applications, features, and/or data from a device  100  of a member of another team/respective MDCF activity network. For example, policeman  432   a  has a headset computer  100  in communication with that of Police Sergeant  431  via MDCF activity network  455 . Policeman  432   a  in his duties at scene  400  investigates identities of victims  403   a, b, c . In his on the scene investigation, policeman  432   a  makes a positive ID of victim  403   c  using police and other records accessed using policemen&#39;s HSC  100  and programs operated thereon. Such data access from the field is supported by a host processor at ambulance  410  and communications through MDCF subnetwork  435 . Policeman  432   a  makes the positive identification and other pertinent facts (say for example medical information) of victim  403   c  known to police sergeant  431  by forwarding data from policemen&#39;s HSC  100  to police sergeant&#39;s HSC  100  via MDCF subnetwork  435 . When police sergeant  431 &#39;s HSC  100  is also part of the collaboration network  455 , the forwarded data about victim  403   c  becomes available to the collaboration team&#39;s  450  (i.e., medical director  421 , police sergeant  431 , and crew boss  441 ) respective HSCs  100 . In turn, from the medical director&#39;s HSC  100 , the forwarded data is accessible (or able to be communicated) to paramedic  422   c &#39;s HSC  100 . The MDCF activity network  425  supports the data transport/communication and sharing. In this example, the forwarded data may be, for example, information on victims  403   c &#39;s blood type, prior recorded medical conditions, drug allergies, etc. In this way, information (generated by a certain application or program) is easily and efficiently shared between teams  430 ,  420  and related across MDCF network/subnetworks  435 ,  455  and  425 , for use by the crucial team member (e.g., paramedic  422   c ) where is HSC  100  is not so programmed (not equipped with a certain application or program). 
     In another aspect, and again with reference to  FIG. 4 , HSCs  100  of members of the police team  420  are equipped with a module that can determine the position of the headset relative to fixed coordinates (e.g., the earth, by using, for example, a global positioning system (GPS) module) or relative to another object (e.g., the ambulance, the headset of another user, or the concentration center of a group of HSCs  100 ). For example, when policeman  432   b  arrives on scene  400 , a processor in his headset  100  determines, based on position data from the GPS module in his headset, that he is within 100 yards of police sergeant  431  (who also has a headset with a GPS module). Accordingly, based on physical proximity, the accept-request process of  FIG. 3  is initiated, and the HSCs  100  of the sergeant  431  and policeman  432   b  join in a network, e.g., subnetwork  435 . 
     When medical director  421  arrives at scene  400 , his HSC  100  determines (using GPS location data) that he is also within a threshold distance from police sergeant  431 , e.g., 100 yards. Accordingly, his HSC  100  joins the subnetwork  455 . These threshold distances can be predetermined and programmed into the headsets HSC  100 . When medical director  421  leaves the scene  410 , subnetwork  425  is maintained by the HSC  100  of paramedic  422   c  acting as a proxy. 
     Identifiers associated with the various HSCs  100  can be used to convey a multitude of information about the permissions, access, and connectivity available to and from a given HSC  100 , the networks and subnetworks which that HSC  100  can join, the order in which it will join those networks and subnetworks, and so on, as well to convey hierarchies of priority, permissions, and proxies for various HSCs  100 . For example, an identifier associated the HSC  100  of police sergeant  431  could identify him as belonging to police team  430  and having a hierarchical or functional rank corresponding to his duties as sergeant. Thus, his HSC  100  might be assigned the identifier “P-3”, where the “P” identifies as a member of the police team, and the “3” identifies a rank of sergeant. A police lieutenant, captain, and deputy chief, might, under this same scheme, have HSCs  100  identified as P-4, P-5, and P-6, respectively, with the rising number after the “P” corresponding to increasing rank. The identifier associated the HSC  100  of policeman  432   a  under this scheme might be “P-2’ (if a senior police officer), and  432   b  might be “P-1” (if a junior officer). Additional information could be included in an identifier string, such as whether the individual associated with that HSC  100  (or with the account that is logged in at that HSC  100 ) has permission to view classified or sensitive information. For example, in an expanded identifier string scheme, a third digit could be added, such as “a,” “b”, “c,” and “x”, corresponding to no security clearance, clearance to see confidential information, clearance to see secret/sensitive material, and top secret clearance, respectively. 
     Accordingly, police sergeant  431 &#39;s HSC  100  might have the identifier “P-3-b” with the last digit indicating that he can see confidential information, such as personnel reports, certain sensitive databases, and so on. Suppose that policeman  432   a &#39;s HSC  100  has an expanded identifier of “P-2-a.” Subnetwork  435  can be configured to block access from the headset of policeman  432   a  to “b” level content on the HSC  100  of police sergeant  431 , while permitting access to other applications, programs, content, and so on that does not require any security clearance. 
     Continuing with the example of the police sergeant  431  and the policeman  432   a , when sergeant  431  leaves the scene, functions performed by the HSC  100  of his HSC  100  can be transferred to another HSC  100 , such as for example, the HSC  100  of the individual on scene having the next lower rank in the police hierarchy; in this example, this would be (senior) policeman  432   a , whose HSC  100  has an identifier of “P-2-a”, the middle digit “2” being subordinate and next lower in rank to that of the sergeant  431  (having identifier “P-3-b.”) The transferred functions can include the role within the subnetwork  430  (police network), within the coordination network  450 , or both. As people leave the scene, subnetworks can be rearranged. For example, if only policemen  432   a,b  crewman  422   b , and paramedic  403   b  remain on scene, then coordination might best be achieved by joining all of these users&#39; HSCs  100  in single network, the complexity of subnetworks no longer being required. Conversely, in a situation with a very large number of individuals, multiples levels of subnetworks could be established (i.e., networks within networks within networks, and so on). 
     It should be further appreciated that the ad hoc nature of the alliances of the HSCs  100  of various individuals, each having identifiers corresponding to roles and/or ranks within those roles can, in some embodiments, be subjected to a confirmation process within the HSCs  100  of users or at a central location For example, users of HSC  100 s can be given the option of joining a particular network or subnetwork, prior being joined. In addition, users of HSCs  100 , such as prime users, can be given the option of denying or other modifying the access level of HSCs  100  within range. For example, a deputy chief might arrive at scene  400  in a mobile command station. Using a computer workstation in the command vehicle, the deputy chief opens a computer application that maps the ad hoc network that has been formed by the various HSCs  100  on the scene. The image displayed to him on the screen of the workstation could be similar to that shown in  FIG. 4 , i.e., a diagram showing the individuals and the networks or subnetworks. In some embodiments, the display would also provide GPS coordinates. Using this computer application, the deputy chief starts to manually modify the ad hoc networks by adding or removing users&#39; HSCs  100  from those networks. This can be done to maximize efficiency of the operation and/or performance of the networks or subnetworks, such as by reducing burden, conserving bandwidth, allocating resource most efficiently, and so on. For example, the deputy chief might order policeman  432   a  to head down the street to direct traffic away from the vicinity of the site. In this new role, policeman  432   a  does not require connectivity to network  435 , but his HSC  100  is still within range of the Wi-Fi from ambulance  410 , so the deputy chief manually excludes him from the subnetwork using the control application on his computer workstation. In this manner, network resources are conserved. 
     While the methods and systems of networking have been explained herein in relation principally to HSC  100 , it should be appreciate that they can be applied more generally to network any digital processing devices. 
     While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.