Patent ID: 12250124

DETAILED DESCRIPTION OF THE DRAWINGS

FIGS.1A and1Bdepict a general-purpose computer system100, upon which the various arrangements described can be practiced.

As seen inFIG.1A, the computer system100includes: a computer module101; input devices such as a keyboard102, a mouse pointer device103, a scanner126, a camera127, and a microphone180; and output devices including a printer115, a display device114and loudspeakers117. An external Modulator-Demodulator (Modem) transceiver device116may be used by the computer module101for communicating to and from a communications network120via a connection121. The communications network120may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection121is a telephone line, the modem116may be a traditional “dial-up” modem. Alternatively, where the connection121is a high capacity (e.g., cable) connection, the modem116may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network120.

The computer module101typically includes at least one processor unit105, and a memory unit106. For example, the memory unit106may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module101also includes a number of input/output (I/O) interfaces including: an audio-video interface107that couples to the video display114, loudspeakers117and microphone180; an 1/0 interface113that couples to the keyboard102, mouse103, scanner126, camera127and optionally a joystick or other human interface device (not illustrated), or a projector; and an interface108for the external modem116and printer115. In some implementations, the modem116may be incorporated within the computer module101, for example within the interface108. The computer module101also has a local network interface111, which permits coupling of the computer system100via a connection123to a local-area communications network122, known as a Local Area Network (LAN). As illustrated inFIG.1A, the local communications network122may also couple to the wide network120via a connection124, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface111may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface111.

The 1/0 interfaces108and113may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices109are provided and typically include a hard disk drive (HDD)110. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive112is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu ray Disc™), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system100.

The components105to113of the computer module101typically communicate via an interconnected bus I04and in a manner that results in a conventional mode of operation of the computer system100known to those in the relevant art. For example, the processor105is coupled to the system bus104using a connection118. Likewise, the memory106and optical disk drive112are coupled to the system bus104by connections119. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple Mac™ or a like computer system.

The methods as described herein may be implemented using the computer system100wherein the processes ofFIGS.3to15, to be described, may be implemented as one or more software application programs133executable within the computer system100. In particular, the steps of the methods described herein are effected by instructions131(seeFIG.1B) in the software133that are carried out within the computer system100. The software instructions131may be formed as one or more code modules, each for performing one or more particular tasks.

The software may be stored in a non-transient computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system100from the computer readable medium, and then executed by the computer system100. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system100preferably effects an advantageous apparatus for detecting and/or sharing writing actions.

The software133is typically stored in the HDD110or the memory106. The software is loaded into the computer system100from a computer readable medium, and executed by the computer system100. Thus, for example, the software133may be stored on an optically readable disk storage medium (e.g., CD-ROM)125that is read by the optical disk drive112. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer system100preferably effects the computer-implemented method for extracting content from a physical writing surface.

In some instances, the application programs133may be supplied to the user encoded on one or more CD-ROMs125and read via the corresponding drive112, or alternatively may be read by the user from the networks120or122. Still further, the software can also be loaded into the computer system100from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system100for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray™ Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCM CIA card and the like, whether or not such devices are internal or external of the computer module101. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module101include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The second part of the application programs133and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display114. Through manipulation of typically the keyboard102and the mouse103, a user of the computer system100and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers117and user voice commands input via the microphone180.

FIG.1Bis a detailed schematic block diagram of the processor105and a “memory”134. The memory134represents a logical aggregation of all the memory modules (including the HDD109and semiconductor memory106) that can be accessed by the computer module101inFIG.1A.

When the computer module101is initially powered up, a power-on self-test (POST) program150executes. The POST program150is typically stored in a ROM149of the semiconductor memory106ofFIG.1A. A hardware device such as the ROM149storing software is sometimes referred to as firmware. The POST program150examines hardware within the computer module101to ensure proper functioning and typically checks the processor105, the memory134(109,106), and a basic input-output systems software (BIOS) module151, also typically stored in the ROM149, for correct operation. Once the POST program150has run successfully, the BIOS151activates the hard disk drive110ofFIG.1AActivation of the hard disk drive110causes a bootstrap loader program152that is resident on the hard disk drive110to execute via the processor105. This loads an operating system153into the RAM memory106, upon which the operating system153commences operation. The operating system153is a system level application, executable by the processor105, to fulfil various high-level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface. It is now common for multiple independent operating systems to be hosted on the same processor105using so-called virtualization applications.

The operating system153manages the memory134(109,106) to ensure that each process or application running on the computer module101has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system100ofFIG.1Amust be used properly so that each process can run effectively. Accordingly, the aggregated memory134is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system100and how such is used.

As shown inFIG.1B, the processor105includes a number of functional modules including a control unit139, an arithmetic logic unit (ALU)140, and a local or internal memory148, sometimes called a cache memory. The cache memory148typically includes a number of storage registers144-146in a register section. One or more internal busses141functionally interconnect these functional modules. The processor I05typically also has one or more interfaces142for communicating with external devices via the system bus104, using a connection118. The memory134is coupled to the bus104using a connection119.

The application program133includes a sequence of instructions131that may include conditional branch and loop instructions. The program133may also include data132which is used in execution of the program133. The instructions131and the data132are stored in memory locations128,129,130and135,136,137, respectively. Depending upon the relative size of the instructions131and the memory locations128-130, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location130. Alternately, an instruction may be segmented into a number of parts, each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations128and129.

In general, the processor105is given a set of instructions which are executed therein. The processor I05waits for a subsequent input, to which the processor105reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices102,103, data received from an external source across one of the networks120,102, data retrieved from one of the storage devices106,109or data retrieved from the storage medium125inserted into the corresponding reader112, all depicted inFIG.1AThe execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory134.

The disclosed writing detection and sharing arrangements use input variables154, which are stored in the memory134in corresponding memory locations155,156,157. The writing detection and sharing arrangements produce output variables161, which are stored in the memory134in corresponding memory locations162,163,164. Intermediate variables158may be stored in memory locations159,160,166and167.

Referring to the processor105ofFIG.1B, the registers144,145,146, the arithmetic logic unit (ALU)140, and the control unit139work together to perform sequences of microoperations needed to perform “fetch, decode, and execute” cycles for every instruction in the instruction set making up the program133. Each fetch, decode, and execute cycle comprises:

a fetch operation, which fetches or reads an instruction131from a memory location128,129,130;a decode operation in which the control unit139determines which instruction has been fetched; andan execute operation in which the control unit139and/or the ALU140execute the instruction.

Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit139stores or writes a value to a memory location162.

Each step or sub-process in the processes ofFIGS.3to15is associated with one or more segments of the program133and is performed by the register section144,145,147, the ALU140, and the control unit139in the processor105working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program133.

The methods described herein may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the writing detection and sharing methods. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

FIGS.2A and2Bcollectively form a schematic block diagram of a general-purpose electronic device201including embedded components, upon which the writing detection and/or sharing methods to be described are desirably practiced. The electronic device201may be, for example, a mobile phone, a portable media player, virtual reality glasses, augmented reality glasses, or a digital camera, in which processing resources may be limited. Nevertheless, the methods to be described may also be performed on higher-level devices such as desktop computers, server computers, and other such devices with significantly larger processing resources.

As seen inFIG.2A, the electronic device201comprises an embedded controller202. Accordingly, the electronic device201may be referred to as an “embedded device.” In the present example, the controller202has a processing unit (or processor)205which is bidirectionally coupled to an internal storage module209. The storage module209may be formed from non-volatile semiconductor read only memory (ROM)260and semiconductor random access memory (RAM)270, as seen inFIG.2B. The RAM270may be volatile, non-volatile or a combination of volatile and non-volatile memory.

The electronic device201includes a display controller207, which is connected to a display214, such as a liquid crystal display (LCD) panel or the like. The display controller207is configured for displaying graphical images on the display214in accordance with instructions received from the embedded controller202, to which the display controller207is connected.

The electronic device201also includes user input devices213which are typically formed by keys, a keypad or like controls. In some implementations, the user input devices213may include a touch sensitive panel physically associated with the display214to collectively form a touch-screen. Such a touch-screen may thus operate as one form of graphical user interface (GUI) as opposed to a prompt or menu driven GUI typically used with keypad-display combinations. Other forms of user input devices may also be used, such as a microphone (not illustrated) for voice commands or a joystick/thumb wheel (not illustrated) for ease of navigation about menus.

As seen inFIG.2A, the electronic device201also comprises a portable memory interface206, which is coupled to the processor205via a connection219. The portable memory interface206allows a complementary portable memory device225to be coupled to the electronic device201to act as a source or destination of data or to supplement the internal storage module209. Examples of such interfaces permit coupling with portable memory devices such as Universal Serial Bus (USB) memory devices, Secure Digital (SD) cards, Personal Computer Memory Card International Association (PCMIA) cards, optical disks and magnetic disks.

The electronic device201also has a communications interface208to permit coupling of the device201to a computer or communications network220via a connection221. The connection221may be wired or wireless. For example, the connection221may be radio frequency or optical. An example of a wired connection includes Ethernet. Further, an example of wireless connection includes Bluetooth TM type local interconnection, Wi-Fi (including protocols based on the standards of the IEEE 802.11 family), Infrared Data Association (IrDa) and the like.

Typically, the electronic device201is configured to perform some special function. The embedded controller202, possibly in conjunction with further special function components210, is provided to perform that special function. For example, where the device201is a digital camera, the components210may represent a lens, focus control and image sensor of the camera. The special function component210is connected to the embedded controller202. As another example, the device201may be a mobile telephone handset. In this instance, the components210may represent those components required for communications in a cellular telephone environment. Where the device201is a portable device, the special function components210may represent a number of encoders and decoders of a type including Joint Photographic Experts Group (JPEG), (Moving Picture Experts Group) MPEG, MPEG-1 Audio Layer 3 (MP3), and the like.

The methods described hereinafter may be implemented using the embedded controller202, where the processes ofFIGS.3to12may be implemented as one or more software application programs233executable within the embedded controller202. The electronic device201ofFIG.2Aimplements the described methods. In particular, with reference toFIG.2B, the steps of the described methods are effected by instructions in the software233that are carried out within the controller202. The software instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software233of the embedded controller202is typically stored in the non-volatile ROM260of the internal storage module209. The software233stored in the ROM260can be updated when required from a computer readable medium. The software233can be loaded into and executed by the processor205. In some instances, the processor205may execute software instructions that are located in RAM270. Software instructions may be loaded into the RAM270by the processor205initiating a copy of one or more code modules from ROM260into RAM270. Alternatively, the software instructions of one or more code modules may be preinstalled in a non-volatile region of RAM270by a manufacturer. After one or more code modules have been located in RAM270, the processor205may execute software instructions of the one or more code modules.

The application program233is typically pre-installed and stored in the ROM260by a manufacturer, prior to distribution of the electronic device201. However, in some instances, the application programs233may be supplied to the user encoded on one or more CD-ROM (not shown) and read via the portable memory interface206ofFIG.2Aprior to storage in the internal storage module209or in the portable memory225. In another alternative, the software application program233may be read by the processor205from the network220, or loaded into the controller202or the portable storage medium225from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that participates in providing instructions and/or data to the controller202for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, flash memory, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the device201. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the device201include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. A computer readable medium having such software or computer program recorded on it is a computer program product.

The second part of the application programs233and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUis) to be rendered or otherwise represented upon the display214ofFIG.2A. Through manipulation of the user input device213(e.g., the keypad), a user of the device201and the application programs233may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers (not illustrated) and user voice commands input via the microphone (not illustrated).

FIG.2Billustrates in detail the embedded controller202having the processor205for executing the application programs233and the internal storage209. The internal storage209comprises read only memory (ROM)260and random access memory (RAM)270. The processor205is able to execute the application programs233stored in one or both of the connected memories260and270. When the electronic device201is initially powered up, a system program resident in the ROM260is executed. The application program233permanently stored in the ROM260is sometimes referred to as “firmware”. Execution of the firmware by the processor205may fulfil various functions, including processor management, memory management, device management, storage management and user interface.

The processor205typically includes a number of functional modules including a control unit (CU)251, an arithmetic logic unit (ALU)252, a digital signal processor (DSP)253and a local or internal memory comprising a set of registers254which typically contain atomic data elements256,257, along with internal buffer or cache memory255. One or more internal buses259interconnect these functional modules. The processor205typically also has one or more interfaces258for communicating with external devices via system bus281, using a connection261. In some embodiments, the processor205may be a collection of FPGA processors, known as a “graphics card”, in which case the connection261is commonly a PCI-Express bus.

The application program233includes a sequence of instructions262though263that may include conditional branch and loop instructions. The program233may also include data, which is used in execution of the program233. This data may be stored as part of the instruction or in a separate location264within the ROM260or RAM270.

In general, the processor205is given a set of instructions, which are executed therein. This set of instructions may be organised into blocks, which perform specific tasks or handle specific events that occur in the electronic device201. Typically, the application program233waits for events and subsequently executes the block of code associated with that event. Events may be triggered in response to input from a user, via the user input devices213ofFIG.2A, as detected by the processor205. Events may also be triggered in response to other sensors and interfaces in the electronic device201.

The execution of a set of the instructions may require numeric or non-numeric variables to be read and modified. Such numeric variables are stored in the RAM270. The disclosed method uses input variables271that are stored in known locations272,273in the memory270. The input variables271are processed to produce output variables277that are stored in known locations278,279in the memory270. Intermediate variables274may be stored in additional memory locations in locations275,276of the memory270. Alternatively, some intermediate variables may only exist in the registers254of the processor205.

The execution of a sequence of instructions is achieved in the processor205by repeated application of a fetch-execute cycle. The control unit251of the processor205maintains a register called the program counter, which contains the address in ROM260or RAM270of the next instruction to be executed. At the start of the fetch execute cycle, the contents of the memory address indexed by the program counter is loaded into the control unit251. The instruction thus loaded controls the subsequent operation of the processor205, causing for example, data to be loaded from ROM memory260into processor registers254, the contents of a register to be arithmetically combined with the contents of another register, the contents of a register to be written to the location stored in another register and so on. At the end of the fetch execute cycle the program counter is updated to point to the next instruction in the system program code. Depending on the instruction just executed this may involve incrementing the address contained in the program counter or loading the program counter with a new address in order to achieve a branch operation.

Each step or sub-process in the processes of the methods described below is associated with one or more segments of the application program233, and is performed by repeated execution of a fetch-execute cycle in the processor205or similar programmatic operation of other independent processor blocks in the electronic device201.

FIG.3shows a flowchart of a computer-implemented method for changing a configuration of a network120according to a preferred embodiment of the invention. As shown inFIG.4, the network120contains a plurality of devices302a,302b,302c,302d,302e, collectively device302. The devices302are typically heterogenous, meaning that the function of each device302may be different, for example one device302may be a router, while another is a switch, a personal computer, a server, or other devices302that may be connected to the network120. Further, each device302is connected to the network120in a hierarchy, as also shown inFIG.4. For example, a group of devices302cmay be connected to a switch302b, thus the switch302bis in a higher hierarchy level than the group of devices302c. Similarly, a group of switches302bmay be connected to a higher level switch302a, thus the switch302ais in a yet higher hierarchy level than the group of switches302b.

The method ofFIG.3commences, at step301, by discovering, using a link layer protocol, such as LLDP, a first set of network configuration data. In one embodiment, step301includes being provided with a home device whose access credentials are known. Then obtaining information about the identity of the home device by accessing the home device using SSH. Libraries such as Napalm are able to identify the home device by the behaviour of the home device in response to certain SSH commands, as well as packet-layer specific behaviour of the home device. Once the home device has been identified, generic commands may be translated to device-specific LLDP commands using the Napalm library to gather more specific information about the home device. Once all relevant or desired information about the home device has been obtained, the neighbours of the home device are identified by polling active network connections and the process is repeated for each neighbouring device, until all devices on the network are identified.

The first set of network configuration data includes information in relation to each discovered device302, for example, the first set of network configuration data may include a first firmware information relating to the firmware version and/or date of the device302. The first set of network configuration data may also include a first device identity information, relating to one or more of a manufacturer, a model number, a MAC address, or a IMEI number of the device302. The first set of network configuration data may further include a first device configuration information relating to one or more of a port configuration, a firewall configuration, a listing of connected devices, or any other type of configurable settings that may apply to the device302.

The method then proceeds, at step303, by creating, using the first set of network configuration data, a network configuration source of truth310. The source of truth310includes a firmware truth, based on the first firmware information, a device identity truth, based on the first device identity information, a device configuration truth, based on the first device configuration information, and a device hierarchy truth that is determined based on the first device configuration information.

In a preferred embodiment, as shown inFIG.5, the method also includes, at step315, receiving a second set of network configuration data. Preferably, the second set of network configuration data was obtained by conducting a physical site survey of the network120, that is, physically inspecting the identity and location of each device302connected to the network120. The second set of network configuration data preferably includes, in relation to each device302, a physical location information related to a physical location of the device. The second set of network configuration data may also include a physical connectivity information relating to one or more of a port configuration of the device302, an access restriction or capability of the device302, such as capacity of cable trays and conduits. The second set of network configuration data may also include a second firmware information and a second device identity information that a similar in nature to the first firmware information and the first device identity information, but gathered from the physical site survey of the network120.

In the preferred embodiment shown inFIG.5, the source of truth310is created in step303bbased on a combination of the first and second sets of network configuration data by comparing the first set of network configuration data to the second set of network configuration data, while flagging and excluding conflicting information between these data sets. The physical location information and physical connectivity information are added to the source of truth310as a physical location truth and a physical connectivity truth.

To assist the physical site survey used to produce the second set of network configuration data, the method may include step313of creating, based on the first set of network configuration data, a site survey plan320for obtaining the second set of network configuration data. As shown inFIG.12, the site survey plan320preferably includes hierarchical physical location information351, for example information relating to a building, level in the building, room on the level, and location in the room of devices302. The site survey plan320may also include device identity information353and physical location and/or connectivity information that is derivable from the first set of network configuration data, such as identity and number of ports, or identification numbers of the equipment, to be verified by the physical site survey. The physical location information may, for example, be derived from an estimate of the signal quality from known locations of devices302in the network120, as well as time of flight calculations of data transfer between the devices302.

Now that the source of truth310has been created, it is possible to use the various truths in the source of truth310to plan and orchestrate changes to the configuration of the network120. As seen inFIG.3, the method processes such changes in configuration by, at step305, receiving a network configuration change request that may relate to one or more devices302in the network120. The network configuration change request may include details as to how the configuration of the network120is to be altered, in terms of configuration, firmware, connection, and/or presence of each device302. The method proceeds, at step307, by determining a device configuration plan360based on the network configuration change request, the device configuration truth, and the device identity truth.

The device configuration plan360, as shown inFIG.14, includes an updated device configuration information for each device302affected by the network configuration change request350. The updated device configuration information is determined for each device302based on the device identity truth, since each device302may require different configuration information to have the desired effect, due to the heterogenous nature of the devices302. To assist this project, the source of truth310includes a configuration library that allows translation of a generic configuration instruction, contained in the network configuration change request, to a specific configuration instruction adapted to effect the intent of the generic configuration instruction in the specific device302. For example a set of generic instructions as shown below, may be translated to the device specific instructions shown thereafter. The configuration library is a collation of manufacturer-provided user instructions as to how each device302may be configured, that is linked to a generic instruction language for the type of network configurations typically performed by the method.

Generic Instructions:

intent = {″meta″: {″timestamp″: 1644013452,″version″: ″1.0″,},″changes″: {″10.0.3.253″: {″vlans″: {″create″: {″102″: ″Room 102″},″assign″: {″tagged″: ″1/1/12″},″remove″: {″tagged″: ″1/1/11″}}}}}

Device-specific instruction set:

conf tvlan 102description ″Room 102″tagged ethernet 1/1/12no tagged ethernet 1/1/11endwr melogout

As shown inFIG.3, the method continues, with step309, by determining an orchestration plan370based on the network configuration change request, the device identity truth, and the device hierarchy truth. As shown inFIG.15, the orchestration plan370includes an order of devices302affected by the network configuration change request350. Configuration changes to networks120should be carried out in a specific order to avoid a configuration change to a node device, for example a switch, leading to a loss of communication with devices connected to the switch as a result of the configuration change to the switch. To avoid these situations, the orchestration plan370specifies the order372in which the device configuration plan360should be applied. The orchestration plan370is determined based on the hierarchy truth, as well as a hierarchy library, such as a look-up table, that allows, using the generic configuration instructions, the identification of changes to device configuration truths that can be conducted in parallel, and the identification of changes to device configuration truths that must be conducted sequentially, either top-down, or bottom-up. In the example shown inFIG.15, devices302in the arm365must be configured before device302at position367may be configured. The steps of the orchestration plan370are recited in the device configuration plan360, as shown inFIG.14.

Finally, at step311, the method applies the updated device configuration information to each device302affected by the network configuration change request350in the order372of the orchestration plan370.

The method may be used for a variety of situations, for example as shown inFIG.6, new devices302may be desired to be added to the network120. To assist this process, at step317, a network update definition330is created that includes a new device identity information and a new device configuration information relating to devices302to be added to the network120. The network update definition330may also include a new device physical location information, relating to a location in which the device302is to be added, and a new device physical connectivity information, similar in nature to the physical connectivity information. The network update definition330may also, or instead, include a device removal information of devices302that are to be removed from the network120. At step319, a bill of materials340is determined, based on the network update definition330and the source of truth310. As shown inFIG.13, the bill of materials340extends beyond the devices302to be added, and also includes devices302that may be required to allow connection of the devices302to be added to the network120, based on the present capabilities of the network120, as evident from the source of truth310. The bill of materials340may further include materiel that is required to physically connect the devices302to be added to the network120, based on the physical location and physical connectivity truths and the network update definition330.

Returning toFIG.6, the method continues, at step321, by creating a network configuration change request350by comparing the network update definition330to the source of truth310. The network configuration change request350may then be processed as discussed above.

To monitor installation of the devices302to be added to the network120, the method may, as shown inFIG.7include step323of receiving a confirmation that the devices302to be installed to fulfill the network update definition330have been installed. The method then continues at step325by discovering, using the link layer protocol, a third set of network configuration data that is substantially similar to the first set of network configuration data, but contains information relating to the devices302that have been installed. The third set of network configuration data is compared, at step327, to the source of truth310to update the source of truth310with the third set of network configuration data, if the third set of network configuration data is consistent with the network update definition. The method also removes and/or flags conflicts of the third set of network configuration data from the source of truth310, such that information relating to devices that have been removed from, or moved within, the network120is updated.

As the devices302on the network120may occasionally require updates of their firmware, the network configuration change request may relate to a change in firmware instead of, or in addition to, a change in device configuration. As shown inFIG.8, the method may thus also include step329of determining a device firmware plan380based on the network configuration change request350, the device identity truth, and the device firmware truth. The device firmware plan380includes updated firmware information for one or more device affected by the network configuration change request350. The updated firmware information may include information relating to the new firmware version number and/or date, a flashable copy of the new firmware, and/or instructions to flash the new firmware onto the device302from a local or remote source. The method then continues with step333by applying the firmware plan, including the updated firmware information, to the one or more devices affected by the network configuration change request350in the order372of the orchestration plan370. As before the source of truth is updated based on the network configuration change request, at step335.

In an optional step331, the device firmware plan380and the orchestration plan370are produced to an operator for approval of the plans370,380before execution of the plans.

In a preferred embodiment shown inFIG.9, the method also includes step337of receiving an NOC network configuration standard390. As shown inFIG.16, the NOC network configuration standard390includes information relating to allowable firmware versions369, allowed ciphers371that may be used on the network120, and preferred network configuration settings373. Preferably, the NOC network configuration standard390is formatted in terms of the generic, device-agnostic, configuration instruction language, so that the standard can be applied across the heterogenous devices302of the network120. To implement the NOC standard390, the method proceeds with step339of creating a network configuration change request by comparing the source of truth310to the NOC standard390. The NOC standard390may be translated to device-specific configuration instruction language using the aforementioned library, to allow comparison against the source of truth310.

The resulting network configuration change request includes a device configuration plan360and/or a device firmware plan380such that, after application of the network configuration change request as previously discussed, the source of truth310is compliant with the NOC network configuration standard390.

In another preferred embodiment shown inFIG.10, the method also includes step341of receiving a second network configuration standard. The second network configuration standard400includes similar information to the NOC network configuration standard390. Typically the NOC network configuration standard is issued by device manufacturers, while the second network configuration standard may be a standard applied by an owner of the network120, or be an obligation the owner of the network120has, such as a franchise agreement. A common industry term is “brand standard”, as is commonly applied in, for example, hotels so that a user experience of the network120is substantially similar between different locations of the same brand. Preferably, the second network configuration standard400is formatted in terms of the generic, device-agnostic, configuration instruction language. To implement the second standard400, the method may proceed with step345of creating a network configuration change request by comparing the source of truth310to the second standard400. The second standard400may be translated to device-specific configuration instruction language using the aforementioned library, to allow comparison against the source of truth310.

The resulting network configuration change request350includes a device configuration plan360and/or a device firmware plan380such that, after application of the network configuration change request350, the source of truth310is compliant with the second network configuration standard400.

The NOC and second standards390,400may also be applied to a network configuration change request350that was created in a different portion of the present method. In this instance, the network configuration change request is, at step343, compared to the NOC and second standards390,400to alter, add, and/or delete portions of the device configuration plan360and/or the device firmware plan380such that, after application of the network configuration change request350, the source of truth310is compliant with the standards390,400.

In another preferred embodiment shown inFIG.11, periodically, after a time interval, for example after 24 h, 7 days, 1 month, 3 months, 6 months, or 1 year, the method includes step347of discovering, using the link layer protocol, the third set of network configuration data and, at step349, comparing the third set of network configuration data to the source of truth310. Conflicts between the third set of network configuration data and the source of truth310are flagged and/or removed from the source of truth310.

Following processing of the network configuration change request, the source of truth310is updated based on the network configuration change request.