Intercom management system

The intercom management system addresses the inefficiencies in existing intercom systems by providing a management application and bridge service for efficient configuration and operation, improving communication and access control in dynamic environments.

WO2025056977A1PCT designated stage expired Publication Date: 2025-03-20ROBERT BOSCH GMBH
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
PCT/IB2024/000522
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-09-14
Filing Date
2024-09-13
Publication Date
2025-03-20

AI Technical Summary

Technical Problem

Existing intercom systems lack efficient management and configuration tools, particularly for special event production crews, which hinders effective communication and access control in dynamic environments.

Method used

The proposed intercom management system includes a management application that configures intercom devices, assigns ports and designations, and enables communication settings, along with a bridge service that facilitates communication between the management application and intercom devices.

Benefits of technology

This system enhances communication efficiency and access control by providing a centralized management platform for intercom devices, allowing for easy configuration and operation, especially in complex environments like sports events or media studios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure IB2024000522_20032025_PF_FP_ABST
    Figure IB2024000522_20032025_PF_FP_ABST
Patent Text Reader

Abstract

An intercom management system to administer operation and configuration, the system including an intercom, a peripheral device, an electronic processor configured to execute a bridge service, the bridge service configured to enable communication between the intercom and a computer over a connection. The computer is configured to connect to the intercom via the connection, generate a user interface, in response to receiving a first input via the user interface, assign the peripheral device to a port, and in response to receiving a second input via the user interface, assign a designation for the peripheral device.
Need to check novelty before this filing date? Find Prior Art

Description

INTERCOM MANAGEMENT SYSTEMRELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 582,682, filed September 14, 2023, the entire content of which is hereby incorporated by reference.FIELD

[0001] Embodiments, examples, and aspects described herein relate to, among other things, an intercom and methods of managing and operating an intercom.SUMMARY

[0003] An intercom is, typically, a stand-alone voice communication system. Among other uses, intercoms are used by special event production crews. For example, intercoms are used by television crews at sporting events. Some intercoms include a master station and multiple substations, interconnected through a communication network that facilitates bidirectional audio and optionally video communication over short distances. The master station offers control functionalities for initiating and receiving calls, configuring communication settings, and managing access control features, while substations provide points of communication engagement and are strategically positioned across a defined area, allowing users to interact, exchange information, and potentially verify identities.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 A is a schematic illustration of an intercom, according to some aspects.

[0005] FIG. IB is a schematic illustration of peripheral devices of an intercom, according to some aspects.

[0006] FIG. 2 is a schematic illustration of an alternative configuration of the intercom of FIG. 1A, according to some aspects.

[0007] FIG. 3 is an illustration of a user interface for an intercom, according to some aspects.

[0008] FIG. 4 is an illustration of a user interface for an intercom, according to some aspects.

[0009] FIG. 5 is an illustration of a user interface for an intercom, according to some aspects.

[0010] FIG. 6 is a block diagram of a software architecture of the intercom of FIG. 1A, according to some aspects.

[0011] FIG. 7 is a block diagram of a software architecture of the intercom of FIG. 1A, according to some aspects.

[0012] FIG. 8 is a flowchart illustrating a process of configuring the intercom of FIG. 1A, according to some aspects.DETAILED DESCRIPTION

[0013] Before any aspects, features, or instances are explained in detail, it is to be understood that the aspects, features, or instances are not limited in their application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. Other instances are possible and are capable of being practiced or of being carried out in various ways.

[0014] Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The terms “mounted,” “connected” and “coupled” are used broadly and encompass both direct and indirect mounting, connecting, and coupling. Further, “connected” and “coupled” are not restricted to physical or mechanical connections or couplings, and can include electrical connections or couplings, whether direct or indirect. Also, electronic communications and notifications may be performed using any known means including wired connections, wireless connections, etc.

[0015] Unless the context of their usage unambiguously indicates otherwise, the articles “a,” “an,” and “the” should not be interpreted as meaning “one” or “only one.” Rather these articles should be interpreted as meaning “at least one” or “one or more.” Likewise, when the terms “the” or “said” are used to refer to a noun previously introduced by the indefinite article “a” or “an,” “the” and “said” mean “at least one” or “one or more” unless the usage unambiguously indicates otherwise.

[0016] It should also be understood that a plurality of hardware and software based devices, as well as a plurality of different structural components may be utilized in various implementations. Aspects, features, and instances may include hardware, software, and electronic components or modules that, for purposes of discussion, may be illustrated and described as if the majority of the components were implemented solely in hardware. However, one of ordinary skill in the art, and based on a reading of this detailed description, would recognize that, in at least one instance, the electronic based aspects of the invention may be implemented in software (for example, stored on non-transitory computer-readable medium) executable by one or more processors.

[0017] In addition, although certain drawings illustrate hardware and software located within particular devices, these depictions are for illustrative purposes only. In some embodiments, the illustrated components may be combined or divided into separate software, firmware and / or hardware. For example, instead of being located within and performed by a single electronic processor, logic and processing may be distributed among multiple electronic processors. Regardless of how they are combined or divided, hardware and software components may be located on the same computing device or may be distributed among different computing devices connected by one or more networks or other suitable communication links.

[0018] Thus, in the claims, if an apparatus or system is claimed, for example, as including an electronic processor or other element configured in a certain manner, for example, to make multiple determinations, the claim or claim element should be interpreted as meaning one or more electronic processors (or other element) where any one of the one or more electronic processors (or other element) is configured as claimed, for example, to make some or all of the multiple determinations. To reiterate, those electronic processors and processing may be distributed.

[0019] For ease of description, some or all of the example systems presented herein are illustrated with a single exemplar of each of its component parts. Some examples may not describe or illustrate all components of the systems. Other instances may include more or fewer of each of the illustrated components, may combine some components, or may include additional or alternative components.

[0020] Before additional details of various aspects, features, and examples are provided, a brief overview of intercoms (sometimes referred to as an intercom system) is provided. In general, an intercom includes a number of hardware and software elements connected within a network. Many intercom systems include a master station, a plurality of substations (or hardware peripheral devices configured to send / receive auto within the intercom system), a communication channel, audio and video components, call initiation means, two-way communication means, and access control features. The master station serves as a control unit with advanced functionalities for initiating and receiving calls, managing communication settings, and configuring access control or settings / features of the system. The substations are distributed throughout a defined area, such as a sports stadium or a news broadcast facility, and enable communication with the master station and other substations.

[0021] The communication channel establishes communication links between the master station and substations. Depending on the application, wired and / or wireless technologies may be utilized for transmitting audio and video signals. Call initiation is enabled through activation mechanisms on substations or via the master station, triggering an audible alert upon call initiation. In many intercom systems, the two-way communication is enabled through integrated microphones and speakers. Users of the master station or the sub stations may engage in oral communication by speaking into the microphone, with audio signals transmitted between the caller and recipient. The intercom system detailed below encompasses applications across various environments and improves upon existing systems by enhancing features of the master station and substations, as well as providing an improved user interface.

[0022] FIG. 1A schematically illustrates an intercom system 100 according to some aspects. In some instances, the intercom system 100 includes a management application 105, a bridge service 110, and an intercom 115. In some instances, the intercom 115 is illustrated as a network of devices (such as illustrated in FIG. IB), and the management application 105 enables configuration of the various devices connected to the intercom 115. For example, as described in greater detail below, the management application 105 may configure a key panel for use over an assigned port, assign a label or descriptor to the key panel, or similar customizable configurations.

[0023] The management application 105 is run or executed on a computer 120. As an aside it should be noted that as used herein when referring to various software, run and execute arc used interchangeably. The computer 120 includes an electronic processor 125, an input / output interface 130, and a memory 135. In other examples, the electronic processor 125 may be implemented as a microcontroller (with memory 135 on the same chip). In other examples, the electronic processor 125 may be implemented using multiple processors.

[0024] In addition, the electronic processor 125 may be implemented partially or entirely as, for example, a field-programmable gate array (FPGA), an applications specific integrated circuit (ASIC), and the like and the memory 135 may not be needed or be modified accordingly. In some examples, the memory 135 includes non-transitory, computer-readable memory that stores instructions that are received and executed by the electronic processor 125 to carry out methods described herein. In one example, the memory 135 stores the management application 105. The input / output interface 130 may include one or more input mechanisms and one or more output mechanisms (for example, general-purpose input / outputs (GPIOs), analog inputs, digital inputs, and others). The bridge service 110 runs on the computer 120 or a separate server, such as, for example, a server 175 as detailed below.

[0025] The management application 105 includes application components. In one example, those components include a software architecture 145 and an application programming interface (API) 150. In some instances, the software architecture 145 is the arrangement of components enabling the functions of the management application 105, as detailed in FIGS. 6-7. The API 150 utilizes a protocol link 155 (for example, a WebSocket link) to provide communications between the management application 105 and the bridge service 110. Protocol link 155 is a computer communications protocol, providing full-duplex communication channels over a single transmission control protocol (TCP) connection. The WebSocket protocol enables interaction between the user interface (such as a web browser) and a server. Full-duplex communication provides more cost-effective communication than half-duplex alternatives, such as HTTP polling. The bridge service 110 includes the API 150, middleware 160, and libraries 165. The middleware 160 is a service that exists outside of the management application 105. This allows for the service to be run in numerous configurations. For example, the bridge service can run ona client desktop (e.g., computer 120), a centralized server, and / or on the client desktop as an ad- hoc server.

[0026] The libraries 165 are responsible for establishing and maintaining communication sessions with the intercom 115. The libraries 165 include a module which provides access to intercom settings and properties. When the management application 105 connects to the bridge service 110, the module initializes and connects to the intercom 115 over a user datagram protocol (UDP 170). The connection includes determining the intercom 115 authorization, such as a user authorization. When the authorization is provided, the module then establishes and maintains the session until closed and begins processing data between the management application 105 and the intercom 115. The architecture 145 hosts the management application 105 user interface. In some examples, the architecture 145 includes unidirectional data flows within the architecture 145. This detail is further described below and illustrated in FIG. 6. In some instances, the bridge service 110 is stored and run by a server 175. The server 175 includes an electronic processor 180, an input / output interface 185, and a memory 190. The electronic processor 180, input / output interface 185, and memory 190 may be similar in structure to the examples provided regarding electronic processor 125, input / output interface 130, and memory 135. In some instances, the bridge service 110 is stored and run by the computer 120. In some instances, some of the functions of the bridge service 110 are performed by the server 175, and other functions are performed by the computer 120.

[0027] The API 150 handles all messaging across the protocol link 155. For example, the API 150 handles the client-initiated API requests (e.g., requests sent from the management application 105 or the computer 120) and the service configured to fulfill the API requests (e.g., the bridge service 110, or the server 175). The API 150 also processes inbound responses and updates. The API 150 communicates with the libraries 165. Components of libraries 165 are implemented using entity objects or entities. Entities are pure data storage objects for data, and do not contain any logic. In some examples, entities contain state information regarding various states of the management application 105. The state information includes various visual states in the management application 105, such as dialogs, popup windows, error windows, connection statuses and application version strings. All the entities are held and managed by the entity database. An instance of the entity database allows for easy and quick retrieval of the entities.Each entity is uniquely addressable by a universally unique IDentifier (UUTD). The entity’s UUID and any other initial values are set when an entity is created. After the entity is created, it is then attached to the entity database. In some instances, updates to state information in the model will immediately update elements of the management application 105 user interface. In some instances, the states are handled via Boolean values in the model, while other states contain various strings and statuses critical to the application or visual elements of the management application 105. The visual elements are illustrated in FIGS. 3-5 and described below.

[0028] FIG. IB is a schematic illustration of peripheral devices of an intercom, according to some aspects. In the example shown, the intercom 115 connects to a peripheral device, such as a key panel 191, via a wired or wireless connection. In some instances, a number of peripheral devices connect to the intercom 115 at once. For example, a first key panel 191 and a second key panel 192 may connect to the intercom 115 at the same time. The connection of each key panel 191, 192 is configured and allowed by the management application 105, as detailed below. In some instances, peripheral devices are configured to communicate with each other in addition to the intercom 115. For instance, a third key panel 193 and a fourth key panel 194 may be configured to communicate both with the intercom 115 and directly with each other. Additional peripheral devices may also be connected to the intercom 115, the additional intercom peripheral devices including digital belt packs, access points, in-ear audio devices, or special purpose devices. For instance, a digital belt pack may be worn by a user, enabling them to be mobile while connected with the intercom 115.

[0029] A key panel, such as key panel 191, includes multiple key assignments, one for each of the physical listen and talk keys on the panel. Additional key assignments may also be present, and a typically key panel may have between 2 and 36 key assignments. In some instances, the key panel will have 16 of each key assignment. In other instances, the key panel will have 32 of each key assignment. By selecting one or more of the key assignments, the user of the key panel may select which function they prefer to enable. For example, when the key panel user turns a specific listen key on, the key panel receives the audio from the resource of the associated key assignment. The user will then hear, through the key panel speaker and / or a connected headset, a mix of all the audio corresponding to the listen keys that are turned on. Similarly, when a key panel user turns a specific talk key on, the audio from their microphone(via a microphone attached to the key panel or via the connected headset) is sent to the intercom 115, where it is routed to all the port / key panels currently listening to that resource. In some instances, the talk keys have multiple levels, allowing a single physical talk key to enable multiple resources. The key panel assignments, talk and listen keys are described in greater detail in FIGS. 3-5.

[0030] FIG. 2 is a schematic illustration of an alternatively configured system 200 of the intercom system 100 of FIG. 1A. As previously described regarding system 100, the system 200 includes a management application 105, a bridge service 110, and an intercom 115. The system 200 illustrates a plurality of management applications 105 executed on a plurality of computers 205, and the bridge service 110 executed on a server 210. In some instances, the plurality of computers 205 are similar to the computer 120, and each include an electronic processor, an input / output interface, and a memory. In some instances, the server 210 is similar to server 175, and also includes an electronic processor, an input / output interface, and a memory as previously described. Additionally, or alternatively, a computer 120, 205 may perform the tasks of the server 210, and execute the bridge service 110.

[0031] FIG. 3 is an illustration of a user interface 300 for an intercom, according to some aspects. The user interface 300 (also referred to as a window) includes a main header 305, an intercom manager 310 (also referred to as a intercom manager window), and a key panel editor 315 (also referred to as a key panel editor window). The management application 105 includes action handlers associated with the API 150. The main header 305 includes a button 320 on the left of the main header 305 and an information array 325. Selecting the button 320 causes the main application menu for opening new widgets and saving / loading custom widget layouts to be displayed. The information array 325 may include connection information, such as an address information for one or more peripheral devices, such as a key panel, or connection status for a device connected to the intercom 115.

[0032] The intercom manager 310 provides a display of ports 330 and properties of the ports 330 to the user of the management application 105. The properties of the ports 330 is provided in a list, and allows the user to search, sort, and filter the ports 330 (illustrated further in FIG. 5). In some instances, the intercom manager 310 displays a list of additional resource types availableto the intercom 115, such as, party-lines, special lists, interruptible foldbacks (IFBs), IFB special lists, general purpose inputs / outputs, and the like. The intercom manager 310 additionally allows the ports 330 information to be transferred to a key panel editor 315. In some embodiments, the intercom manager 310 consists of multiple components, including a search bar 335, where the user can search by name, IP address, or other filters. The search bar 335 updates result in real time as the user types, allowing the editor to rapidly refresh during use. The search bar 335 checks for text in the search bar 335 and then works in conjunction with the action handlers to display outputs corresponding to the inputted text. The intercom manager 310 also includes a row of additional buttons with different functionalities.

[0033] The filter button 340 allows the user to filter results displayed on the key panel editor 315, such as filter by used ports 330, resource types, or the like. The filter button 340 may include additional drop-down options, with the filter list dynamically expanding or contracting into the filter button 340 dropdown menu as needed based on the application window size. For example, any port 330 in the list view may be selected and selecting one or more of the ports 330 allows the user to drag and drop the selection throughout the management application 105. Any port in the resource list view may also be drag and dropped once selected to the key panel editor 315 to configure and interact with values of the port 330. For instance, values may include connection status, live status, group status, label, or the like. Additionally, the intercom manager 310 may include a matrix filter button, which allows the user to filter resources by which key panel they are connected to, whether it be via a remote connection or a local connection. In some examples, the matrix filter button is only shown when connected to a supported key panel.

[0034] FIG. 4 is an alternative illustration of a user interface 400 of FIG. 3, according to some aspects. The user interface 400 includes the key panel editor 315 as previously described, and additional elements. The user interface 400 includes assigned ports 330, which may include labels for organizing the peripheral devices connected to the intercom 115. For example, when an intercom 115 is configured for use in a media studio, the group labels may include designations for a director 405, a camera 410, a sound system 415, a talent 420, or other such designations. The user interface 400 also includes separate designations for talk keys 425 and listen keys 430. A user of the interface 400 is able to configure the current state of the key options for each of the talk and listen keys. As illustrated, each of the key option assignmentsincludes a color for easier recognition of the assigned group. In some examples, this color assignment may be toggled via the key panel editor 315. Assignments may also be shown / hidden by a user, fdtered (e.g., by utilizing the fdter button 340), searched for or edited.

[0035] Assignments may be directly entered by the user or may be copy / pasted from previously assigned ports 330. Additionally, assignments may be copied between key panel editor 315 windows. Key assignments may also be dragged and dropped from one window to another, or from one port 330 to another, or from one key assignment to another key assignment. For example, a user may partially or fully duplicate a key panel editor 315 window or a key assignment. If a particular key is restricted, the user is prevented from changing the assignment directly from the key panel editor 315. For example, when a talk or listen key is restricted, the assignments may not be changed by the user of the key panel. In some instances, the volume levels illustrated in the key panel editor 315 affect the volume when listening point-to-point, or party-line, for resources associated with the listen key 430. In this instance, the restriction does not affect the audio sent to other key panels. In some instances, the user may change a state of one or more of the assignments. For example, the user may mute / unmute the talent 420, or modify the volume of either the talk key or listen key assignments. Modifications made to any or all of the key panel editor 315 assignments may be saved and reloaded at a later time.

[0036] Different assignments may include different levels of use. For example, the talk key 425 designation allows one key panel, such as key panel 193, to transmit audio broadcasts to another key panel, such as key panel 194, and the listen key 430 designation allows to receive audio broadcasts. The same key panel may have both talk and listen key assignments, or only one assignment. For example, the director 405 assignment may enable the director 405 key panel to both transmit and receive broadcasts. Another assignment, such as the camera 410, may only be able to receive broadcasts. In some examples, more than one key panels are assigned to the same group label (or group). For instance, there may be more than one key panel with the camera 410 designation. The group label is determined by the user of the management application 105 and may be customized by the user.

[0037] FIG. 5 is an alternative illustration of a user interface 500 of FIG. 3, according to some aspects. As previously described, the intercom manager 310 includes a search bar 335which enables the user to search the management application 105. For example, the user may search for available ports 330 in order to assign a particular port to peripheral device connected to the intercom, such as key panel 191. The user may search by name, IP address, port, or other fdters. In some instances, the search bar updates result in real time as the user types, instead of having to press enter or a similar input. During a query, the search checks for text in the search bar 335 and then works as previously described. Once complete, the search results populate in the intercom manager 310. For example, if a user searched for “dir,” (e.g., abbreviate of “director”) the search results would return both a directory alpha of “dir” and any descriptions including at least “dir” within the description.

[0038] FIG. 6 is a block diagram of a software architecture 600 of the intercom of FIG. 1A, according to some aspects. As previously described, the architecture 145 hosts the management application 105 user interface, such as previously illustrated user interface 300, 400. In some examples, the architecture 145 includes unidirectional data flows within the architecture. The architecture 145 includes of five main components: views 605, actions 610, action handlers 615, services 620, and models 625. The views 605 contain elements of the user interface 300, 400, such as windows or pages displaying the intercom manager 310. Actions 610 are command objects generated from the user interface when the user executes a change to the user interface. Action handlers 615 are logic components which route and process the actions 610. Services 620 are logic components that interacts with external systems, such as executing changes from the management application 105 to the intercom 115, or changes to one or more of the peripheral devices. Models 625 are data objects which hold information necessary for the views 605, such as assigned ports 330 or key designations.

[0039] For example, when the user interacts with the view 605, the view 605 propagates an action 610 through an action handler 615, to the various model 625 that hold the management application 105 data and logic. The affected view 605 is then updated based on changes to the models 625. The action handler 615, models 625 and views 605 are independent nodes with distinct inputs and outputs. The actions 610 are objects containing the new data and identifying properties. As previously described, the view 605, action handler 615 and models 625 communicate via unidirectional flow of data. Service 620 can be called from an action handler 615 but only communicate with the rest of the system via actions 610.

[0040] FIG. 7 is an expanded block diagram of the software architecture 600 of FIG. 6, according to some aspects. As previously described and illustrated in FIG. 6, the Architecture 145 includes views 605, actions 610, action handlers 615, services 620, and models 625. The views 605 are the graphical portion of the management application 105 which displays information and accepts input from the user. Elements of the views 605 are previously described user interface 300, main header 305, intercom manager 310, and key panel editor 315. The views 605 send actions into the action handler 615 which implements the logic needed to process the triggered action. In some examples, these actions include sending messages through API 150 based on certain events, or directly updating the management application 105 state information in the models 625.

[0041] Actions are provided to the action handler 615 and originate from user interactions with the views 605. All data flows through an action handler 615. When the action handler receives an action 610, the action handler 615 executes the function that the models 625 have registered with the action 610. The models 625 respond to whichever actions 610 are relevant to the management application 105 state they maintain. The models 625 then emit a change event to alert the views 605 that a change to the data layer has occurred. In some instances, there are four action handlers: an application action handler 705, a resource finder action handler 710, a port editor action handle 715, and an API action handler 720. The application action handler 705 contains actions generated from the main window (e.g., opening or closing of the application) or changes in application dialog visibility state. For example, the application action handler 705 may handle actions such as user interactions with the main header 305, the intercom manager 310, or the key panel editor 315, or actions 610 such as opening or closing the management application 105.

[0042] The resource finder action handler 710 includes actions 610 related to the searching or filtering for key assignable resources, such as search queries generated from the intercom manager 310. These actions 610 are generated when the user searches with a text string, filters the port list using the resource type filter, or sorts the resource list view. The port editor action handle 715 actions 610 are generated from the key panel editor 315. The port editor action handle 715 includes actions 610 such as setting / changing the individual fields in a key panel or assigning talk keys 425 and listen keys 430. In some instances, API action handler 720 handlesactions 610 associated with the API 150. These actions 610 cover a broad range of functionality in the management application 105 and include managing the bridge service 110 and intercom 115 connection states, managing key panel authentication, and populating it management application 105 states based on data received from the API 150.

[0043] In some examples, the services 620 component is responsible for handling logic for the management application 105. Services 620 perform such actions 610 as fdtering and validating inbound data changes from the views 605, creating new entities with default values, and setting relationships between entities. Each of the services 620 have an identifier which is used to access the service 620. For example, one of the services 620 is the application settings service 722, which is responsible for reading and writing the configuration files saved within the memory 135. The application settings service 722 handles actions 610 such as opening the settings file from a specified file path, and the saving the settings file to the specified file path. The services 620 also include the API 150 service, which is responsible for processing requests and receiving updates from the API 150 driver. In some examples, the services 620 are also responsible for handling external resources 745, such as application settings 750 set from outside the management application 105.

[0044] The models 625 include application state models 725, intercom model 730, resource models 735, and port editor models 740. The application state models 725 handle the state information, including various visual states in the management application 105 as previously described. The intercom model 730 stores information about the key panels that communicate with the system 100, such as their connection status and device type. The connection status of the key panel will inform the management application 105 as to which states should be changed, such as when a peripheral device, such as key panel 191, requires authentication, or if the intercom 115 or the key panel 191 is attempting to connect to management application 105. The intercom model 730 also stores information stored by the key panel 19 litself, such as its description, frame / port count, or its max sessions. The intercom model 730 also stores Boolean values that determine whether settings on the key panel are enabled, such text or Unicode support. The resource models 735 include information about one or more of the intercom 115 resources, such as peripheral device type, configurable length names for the resource types, or descriptions that are contained within the resource models 735. Additionally, the resourcemodels 735 include Boolean values that store information about whether a given resource has various properties enabled, such as key assignments. The port editor models 740 store information about which port 330 and setup page are currently active within the management application 105, and also store information about the currently connected key assignment, such talk and listen assignments on within the key panel editor 315. Utilities 755 is responsible for logging, such as changes made via the views 605 or actions 610 performed by the action handler 615.

[0045] FIG. 8 is a flowchart illustrating a process 800 of configuring the intercom of FIG. 1A. The process 800 includes connecting (805) the management application 105 to the intercom 115 such as via a bridge service 110 as described above. In some instances, the management application 105 also connects to a peripheral device, such as the key panel 191. In some instances, more than one peripheral device is connected simultaneously or sequentially. The process 800 includes assigning (810) the peripheral device a port 330 via the management application 105. The assignment of the port 330 enables the peripheral device to communicate with other connected peripherals, as previously described. The process 800 includes assigning (815) a designation to the peripheral device via the management application 105. For example, a designation may include a talk key or a listen key. The designation may be copied from previously configured peripheral devices. For instance, a user may drag and drop a designation to one or more peripheral devices at the same time. Optionally or additionally, the process 800 includes assigning (820) a label to the peripheral device. The label may be any previously described assignment, such as a camera. Optionally, the label may also be copied, dragged, dropped, or moved from one peripheral device to another via the management application 105. The process 800 also includes enabling (825) an operation of the peripheral device based upon the previous assignments (810, 815, 820). For example, the key panel 191 may be enabled to transmit and or / receive audio broadcasts based upon one or more of the assignments (810, 815, 820). Additional peripheral devices may also be configured using the process 800 such that they may communicate with each other, or a specific one of the other peripheral devices connected via the intercom 115.

[0046] Thus, aspects herein provide, among other things, systems and methods of an intercommunication system.

Claims

CLAIMSWhat is claimed is:

1. An intercom system comprising: an intercom; a peripheral device; an electronic processor configured to execute a bridge service, the bridge service configured to enable communication between the intercom and a computer over a connection; wherein the computer is configured to: connect to the intercom via the connection, generate a user interface, in response to receiving a first input via the user interface, assign the peripheral device to a port, and in response to receiving a second input via the user interface, assign a designation for the peripheral device.

2. The system of claim 1, wherein the computer is further configured to enable an operation of the peripheral device based upon the assigned port and the assigned designation.

3. The system of any of claims 1 to 2, wherein an operation of the of the peripheral device includes a talk function and a listen function.

4. The system of any of claims 1 to 3, wherein the computer is further configured to execute the bridge service.

5. The system of any of claims 1 to 4, wherein the electronic processor is located on a server separate from the computer.

6. The system of any of claims 1 to 5, wherein the user interface includes an intercom manager window and a key panel editor window.

7. The system of any of claims 1 to 6, wherein the first input is a drag and drop function.

8. The system of any of claims 1 to 7, wherein the second input is a user defined label for the peripheral device, and wherein the designation includes the user defined label.

9. The system of any of claims 1 to 8, wherein the peripheral device is a key panel or a belt pack.

10. The system of any of claims 1 to 9, the system further comprising a first peripheral device and a second peripheral device, and wherein the computer is further configured to: in response to receiving a first input via the user interface, assign the first peripheral device to a first port, and in response to receiving a second input via the user interface, assign the second peripheral device to a second port, wherein the second input is a drag and drop function.

11. The system of any of claims 1 to 10, wherein the designation includes a listen key and a talk key.

12. A method of enabling an intercom, the method comprising: connecting, via a transmission control protocol (TCP) connection, an intercom to a computer including an electronic processor, assigning, via the electronic processor, a peripheral device to a port, and assigning, via the electronic processor, a designation for the peripheral device.

13. The method of claim 12, the method further comprising: enabling, via the electronic processor, an operation of the peripheral device based upon the assigned port and the assigned designation.

14. The method of any of claims 12 to 13, wherein an operation of the of the peripheral device includes a talk function and a listen function.

15. The method of any of claims 12 to 14, the method further comprising executing a bridge service, via the electronic processor, wherein the bridge service is configured to enable communication between the intercom and the computer over a connection.

16. The method of any of claims 12 to 15, wherein the electronic processor is located on a server separate from the computer.

17. The method of any of claims 12 to 16, the method further comprising: providing a user interface that includes an intercom manager window and a key panel editor window, and receiving a user input, wherein the user input is a drag and drop function.

18. The method of any of claims 12 to 17, wherein the peripheral device is a key panel or a belt pack.

19. An intercom system comprising: an intercom; a first peripheral device; a second peripheral device; an electronic processor configured to execute a bridge service, the bridge service configured to enable full-duplex communication between the first peripheral device, the second peripheral device, and a plurality of computers over a transmission control protocol (TCP) connection; wherein at least one of the plurality of computers is configured to: connect the first peripheral device to the intercom, connect the second peripheral device to the intercom, generate a user interface, in response to receiving a first input via the user interface, assign a first port to the first peripheral device, in response to receiving a second input via the user interface, assign a second port to the second peripheral device,in response to receiving a third input via the user interface, assign at least one designation for the first peripheral device, the designation including a listen key and a talk key, in response to receiving a fourth input via the user interface, assign at least one designation for the second peripheral device, the designation including a listen key and a talk key, and enable at least one operation of the first peripheral device and the second peripheral device based upon the assigned port and the assigned at least one designation.

20. The system of claim 19, wherein at least one of the first input, the second input, the third input, and the fourth input is a drag and drop function.19

Citation Information

Patent Citations

  • Internet protocol (IP) serverless page party (SPP) station and systems and methods for deploying multiple SPP stations

    US20170366672A1

  • Configurable multi-function ruggedized voice over internet protocol (VoIP) communications device with universal application platform

    US20190058783A1