Device configuration management and programming

Abstract

Various systems and methods for managing device configuration are described herein. A device programming system includes: communication circuitry; memory to store instructions; and a processor subsystem, which when executing instructions stored in memory is configured to perform operations comprising: receive, at a device management server, a reference to a configuration template; read, at the device management server, from a datastore via the communication circuitry, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and transmit the device configuration to a gateway, which is physically connected to a hardware device, the gateway configured to program the hardware device using the device configuration.

Description

DEVICE CONFIGURATION MANAGEMENT AND PROGRAMMINGPRIORITY APPLICATION(S)

[0001] This application claims priority to U. S. Provisional Patent Application No. 63 / 736,487, filed on December 19, 2024, the disclosure of which is incorporated by reference herein in its entirety.BACKGROUND

[0002] A smartcard reader is a device designed to interact with smartcards, which are physical cards embedded with integrated circuits capable of processing data. These cards store sensitive information such as personal identification, financial data, or authentication keys. The smartcard reader typically reads the data from the card and may also write to it depending on the application. This interaction is often facilitated through contact or contactless technology. In contact smartcards, the card is inserted into the reader to establish a physical connection with the integrated circuit, while contactless smartcards use radio-frequency identification (RFID) or near-field communication (NFC) technology to communicate wirelessly with the reader. Smartcard readers are commonly used in various applications, including financial transactions, access control systems, and secure data storage.

[0003] The technology behind smartcard readers often involves encryption and authentication protocols to ensure secure communication between the card and the reader. For contact smartcards, the reader establishes an electrical connection to the card’s microprocessor through a set of metallic contacts. In contactless systems, electromagnetic fields are used to transfer data between the card and the reader, which enhances convenience but requires more sophisticated security measures like mutual authentication and encryption to prevent data interception.Readers can be standalone devices or integrated into larger systems like point-of-sale terminals or entry access systems, making them integral to industries like banking, telecommunications, healthcare, and public transportation. With advancements in technology, modem smartcard readers are becoming faster, more secure, and more versatile, supporting multiple card types and communication protocols.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way ofexample, and not limitation, in the figures of the accompanying drawings in which:

[0005] FIG. l is a diagram illustrating an operating environment, according to an embodiment;

[0006] FIG. 2 illustrates three types of inheritance, according to an embodiment;

[0007] FIG. 3 illustrates the values used after resolving the inheritance chain, according to an embodiment;

[0008] FIG. 4 illustrates control and data flow of an Initialization Configuration Template (CT), according to an embodiment;

[0009] FIG. 5 is a table of microservice application programming interface (API) parameters, according to an embodiment;

[0010] FIG. 6 illustrates control and data flow of a Physical Initialization CT, according to an embodiment;

[0011] FIG. 7 is a table of microservice application programming interface (API) parameters, according to an embodiment;

[0012] FIG. 8 illustrates device versioning clauses in a CT, according to embodiments;

[0013] FIG. 9 is a data serialization format formatted text block that illustrates a substitute configuration, according to an embodiment;

[0014] FIGS. 10A-B illustrate a flowchart of a process for posting a configuration with a particular software version, according to an embodiment;

[0015] FIG. 11 illustrates data and control flow in an implementation for CT updates, according to an embodiment;

[0016] FIG. 12 illustrates data and control flow in an implementation for on-demand CT updates, according to an embodiment;

[0017] FIG. 13 illustrates data and control flow in another implementation for on-demand CT updates, according to an embodiment;

[0018] FIG. 14 illustrates the data and control flow in a firmware build system, according to an embodiment;

[0019] FIG. 15 illustrates the request status, according to an embodiment;

[0020] FIG. 16 illustrates the reader status, according to an embodiment;

[0021] FIG. 17 is a flowchart illustrating a method for device programming, according to an embodiment;

[0022] FIG. 18 is a block diagram illustrating an example machine upon which any one or more of the techniques (e.g., methodologies) discussed herein may perform, according to an example embodiment; and

[0023] FIG. 19 is a diagram illustrating a network topology for an on-premises installation, according to an embodiment.DETAILED DESCRIPTION

[0024] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the present disclosure may be practiced without these specific details.

[0025] A device configuration management platform is described herein. The device configuration management platform permits in-the-field (by customers and partners) customizations to be done using the same mechanisms and configuration definitions as are used in the factory. The platform supports creation, access control, and storage management of dynamic, data driven configuration files. Configuration files are used to manage firmware (FW), software (SW), and hardware (HW) components of a programmable device. The platform provides mechanisms to support the configuration of devices as their FW, SW, and HW evolves, including the introduction of new models while providing both backwards and forwards compatibility so existing configurations do not have to be reprogrammed with each new release. The platform is accessible by manufacturing, retail, client, and support entities, so that device configuration can be managed at various stages during its lifecycle.

[0026] A device is manufactured and during the manufacturing process, it is configured. The configuration may be expressed using a formalized data interchange language, such as Yet Another Markup Language (YAML), MessagePack, JavaScript Object Notation (JSON), Binary JSON (BSON), or extended Markup Language (XML). These formats are widely used because they are human-readable and easily parsed by many programming languages, including JavaScript, Python, and Java. After device deployments, a technician may be sent to reprogram or reconfigure the device in the field. The technician may obtain a configuration from the device configuration management platform and use it to reprogram the device. Additionally, or alternatively, device manufacturers, designers, implementers, customers, and others may use programming features to reprogram a device for testing, development, or deployment. These functions and others are described in more detail below.

[0027] FIG. 1 is a diagram illustrating an operating environment 100, according to an embodiment. A device management system 102 is connected to a device database 104. The device management system 102 may be used to manage the manufacture, distribution, installation, deployment, updating, or other aspects of devices. The device management system102 may include a management microservices architecture (MMSA) service, which may be implemented using a plurality of microservices. The devices may be of any type including intemet-of-things (loT) devices, sensors, smartcard readers, controllers, or the like. The device database 104 may be a document database. In various embodiments, the device database 104 is a MongoDB document database, a CouchDB database, an Amazon DocumentDB database, a RethinkDB database, or a MarkLogic database.

[0028] The device management system 102, device database 104, device manufacturer 106, distribution center 108, and customer 110 (via user device 112), may be connected via a network 114. The user device 112 may be of any type of compute device including, but not limited to a mobile device, a desktop computer, a smartphone, a laptop computer, a tablet device, a personal digital assistant, a wearable device (e.g., a smartwatch), or the like. The user device 112 may execute an application (app) provided by the device management system 102 to access the accounts and perform tasks (e.g., ordering devices, checking on order status, etc.). The network 114 may include one or more of local-area networks (LAN), wide-area networks (WAN), wireless networks (e.g., 802.11 or cellular network), the Public Switched Telephone Network (PSTN) network, ad hoc networks, cellular, personal area or peer-to-peer networks (e.g., Bluetooth®, Wi-Fi Direct), or other combinations or permutations of network protocols and network types. The network 114 may include a single local area network (LAN) or wide-area network (WAN), or combinations of LANs or WANs, such as the Internet.

[0029] A document database is a type of NoSQL database designed to store, retrieve, and manage data in the form of documents. Unlike traditional relational databases that use structured tables and fixed schemas, document databases store data in flexible, semi -structured formats like JSON, BSON, or XML, where each document is a self-contained unit of data. Each document can have varying fields, allowing for a more adaptable data model that can accommodate different types of information without requiring schema changes. This makes document databases particularly suited for applications that require rapid development, scalability, and handling of complex, unstructured, or hierarchical data.

[0030] The device database 104 stores configuration templates (CT), universally unique identifiers (UUID), relationships between CTs and UUIDs, and Typed CT definitions. It is understood that additional information may be stored in the device database 104.

[0031] A CT is a versioned template that describes a device’s configuration, which may be a desired configuration (e.g., planned for manufacture), an actual configuration (e.g., operating in the field), or a historic configuration (e.g., a previously used configuration). Versioning is used to support changes in the software on the device, such as the addition of new attributes orchanges in default attribute values. A CT has a lifecycle of Draft, Publishable, Published, and Deactivated. Once Published a CT is locked it cannot be changed except by an administrative override. This is to preserve the history when a CT is applied to a UUTD.

[0032] A CT is a reference (a key value for a database lookup) to a Device Configuration template Each CT contains a data serialization format object that specifies a device configuration. All attributes / value pairs are contained in this one, extensible, object. CTs are typed and the type determines the schema for how the data serialization format object is interpreted / processed by clients that consume the CT’s contents.

[0033] Data serialization format objects within a CT support inheritance. Each link in the inheritance chain logically copies attribute / value pairs from its immediate parent, and then adds its own attribute / value pairs replacing the values for any attributes it specifies were specified in the parent. This inheritance repeats for each step in the chain. All data serialization format objects in an inheritance chain are of the same type.

[0034] Any inheritance chain needs a place to start. This requires the specification of a beginning, default, definition to serve as a starting point; this is the “Initialization CT”.

[0035] In an embodiment, the CT is used to refer to configuration settings for a smartcard reader device. Configuration settings may include Boolean, integer, float, or string values to control and configure various aspects of a smartcard reader device. For instance, the smartcard reader device may have a light-emitting diode (LED), and the color of the LED in various states may be controlled by an attribute set in the CT. Other examples include, but are not limited to, whether encryption is enabled, what type of encryption protocol is used, private keys used for the encryption, whether keypad sounds are enabled on the device, whether lights are activated, whether Bluetooth is enabled, a personal identification number (PIN) or other access code used to access the device configuration, message formats, and the like.

[0036] A UUTD is used to provide a unique reference to a device that is managed within the device management system 102. When a device comes into existence, a UUID entry is created and properly initialized. The UUID is used to record information about the physical device and its state (e.g., software and configuration) evolves over time. Software and configuration information is tracked to support the manageability of the device. The UUID is not used to track application data when a device supports data for its application (e.g., a local database for access rights).

[0037] Relationships between CTs and UUIDs may be tracked and stored in the device database 104. For instance, the CTs used on a particular device identified with a UUID may be tracked to allow for debugging, software or hardware support, billing purposes, or the like.

[0038] The Typed CT defines the schema and automated migration specification that defines differences in content for each supported version. The Typed CT is used to specify all supported or released hardware (HW) and software (SW) revisions, the upgrade methods needed to automatically version CTs as the supported schemas evolve over time, and mappings from the abstract descriptions contained in the CT to device language necessary to actually configure the device.

[0039] In the device database 104, each CT is associated with two documents: a metadata document and configuration description document. The metadata may be used to describe a state or description of a configuration and may include various fields used to identify a CT, a UUTD, a device, an order status, a manufacturing status, create and modify dates, etc. The configuration description document may be used to describe a device configuration, and may include various fields such as a software version, a schema version, an initial configuration (e.g., a CT of a parent or baseline configuration), a substitute configuration, etc.

[0040] At the time of manufacture by a device manufacturer 106, the device is given a UUTD. This UUID is stored in the device database 104. The UUID may be stored along with other information such as the device manufacturer name, a manufacturing date, a lot number, etc. Devices are delivered to a distribution center (DC) 108, where the devices are stored before being sent to a customer 110. The DC 108 may apply a configuration to a device from the manufacturer. This may be a default configuration. The default configuration may have a CT or may be identified with a different unique string, e.g., “YYYYYY”. The configuration used is stored in the device database 104. Customers 110 may have a desired configuration and the DC 108 may apply this customized configuration on behalf of the customer 110. The customized configuration is associated with a CT and its application to the device is stored in the device database 104. For instance, a new record is created for a UUID that stores the new CT applied to the device with the UUID.CTs and Structured Composites

[0041] This section describes CTs and Structured Composites. Configuration settings (e.g., formats, LED colors, etc.) for each configuration are stored in the device database 104 and are referenced by their 6-character CT value. These CT values are created and stored in the device management system 102 and are referenced by customers 110 when they order the devices using a “Structured Composite.”

[0042] CTs can be either Complete or Incomplete. Incomplete CTs require additional information to be provided. Complete CTs do not require additional information. Customconfigurations are used in “part numbers” that have a limited length to fit into compatible manufacturing systems. There is space for only six characters for this portion of the Structured Composite.

[0043] CTs may be identified with multi -character IDs, which can be assigned serially (YYYY01, YYYY02, . . .), in an alphanumeric format. With a 6-character size, this allows for a total of 2,176,782,335 combinations (e.g., “YYYYYY” in base 36). In order to avoid confusion, the letters B, I, O and Z may not be used to avoid confusion with the numbers 8, 1, 0 and 2. So, base-32 may be used instead. Further, in order to ensure that these IDs do not contain offensive values, the use of offensive words (in whole or in part) may be screened or filtered out. The offensive word list is configurable and may include various disparaging words (e.g., swear words, racial slurs, etc.), sensitive words (e.g., anatomical names), protected words (e.g., trademarks or trade names), proper nouns, or the like.

[0044] A “Structured Composite” is the name used by the customer 110 when ordering a device. This is a construct that is used for enterprise resource planning (ERP) systems, and it is separately maintained outside of the CT data serialization format structure. For instance, the Structured Composite may be stored in a product lifecycle management platform, enterprise business systems (company databases and the tools and processes that surround them), customer relationship management platforms, or manufacturing systems. CTs are, largely, independent from the specific hardware they are used to configure.

[0045] The Structured Composite includes a plurality of segments or sections, such as a hardware device segment, a software license segment, a CT, and an optional customer tag. The Structured Composite is to specify the physical hardware that is purchased (the first segment), and the remote terminal unit desired for the firmware that resides in the device (the second segment). The desired configuration (as specified in the CT) is the third segment of the Structured Composite. The segments in the Structured Composite may be separated by a delimiter, such as a dash, double dash, semicolon, colon, slash, or the like.

[0046] A default CT may be used on stock (e.g., non-customized) devices. Specifying a CT of “YYYYYY” within a Structured Composite is not a direct reference to a CT. Instead, it is a specification that a baseline (or backing) CT should be used. In an embodiment, to determine the hardware information to be used, a “Backing” CT is obtained from a table indexed by a wildcard string matched with the hardware segment and other information that specifies the target CT.

[0047] As an example, a Structured Composite may have a regular expression of the hardware segment of “*-LLL” with “-L01” indicating a particular software license segment of the Structured Composite. There may be a number of “*-L01” devices, such as “RD01-L01”,“RD02-L01”, and “RD03-L01”, which may refer to various hardware device segments that all use the “L01” software license segment. Using a regular expression in the hardware segment of the Structured Composite and a “YYYYYY” in the CT segment of the Structured Composite indicates that a backing (or baseline) CT is to be determined and used. So, for a Structured Composite of “RD01-L01 -YYYYYY”, “RD02-L01 -YYYYYY”, or “RD03-L01 -YYYYYY”, a backing CT of “YYYY01” may be found in the table and used as the baseline or backing CT as an initial programming of the device.

[0048] A Structured Composite may have a plurality other components for description data fields, such as long and a concise, associated with the description type. These are dynamically generated. Both the concise and long descriptions communicate the essence of a configuration for use on purchase orders (POs), reference documentation, online information repositories, and summary information in tool interfaces.

[0049] The concise and long descriptions are composed of several description elements which are assembled in a specific order. These description elements are defined in a Structured Composite Description mapping document, which defines: a. Type (concise, long) b. Search criteria (what to look for in the data serialization format) c. Description Element (value to be used in the Descriptions) d. Order of generation e. Special handling rules

[0050] The contents of the mapping document are stored in the device database 104, using dynamic lookups that allow ‘on-the-fly’ changes to be implemented. A query, stored procedure, or other database operation may be used that generates the Descriptions based on the information found in the dynamic lookups. The descriptions for a CT are refreshed every time that they are referenced in an order system (e.g., placed on orders, patched) to ensure that the descriptions reflect the latest mapping.

[0051] The long description data field may be typically lengthy in its content (e.g., up to 4000 characters). The concise description data field may be shorter (e.g., up to 240 characters long).On-demand Population of Manufacturing and Distribution Center Databases

[0052] Manufacturers 106 and distribution centers 108 maintain separate environments so that manufacturing and distribution operations are able to continue even during network outages that block access to the device management system 102. The device management system 102 may continue to generate work orders (WO) and purchase orders (PO) when an order for adevice is processed and scheduled for execution. To properly process a workorder for a Structured Composite that contains a reference to a CT, the device manufacturer 106 and distribution center 108 maintain a datastore (database) with all Structured Composites for all supported FW Releases for all supported HW Models.

[0053] Manufacturing and production control systems may be grouped into an Operations Solutions (OS) system. Each device manufacturer 106, which is a production facility, runs an instance of the OS software tools. A portion of these tools is the OS datastore (also referred to as OS Cache) where all of their data lives.

[0054] When a CT is flagged as available, an enterprise business service (e.g., an order processing system) wakes up and generates popular Structured Composites associated with the CT. A microservice within a management microservices architecture (MMSA) service is invoked with the list of Structured Composites. That microservice, in turn, has access to the manufacturing datastore. The definitions are then populated into the manufacturing datastore (e.g., at a device manufacturer 106) so any orders processed can be produced. It is often the case that the owner of a CT will mark it available and then immediately place an order for the custom configured device.

[0055] As new CTs are created that are marked as “available = TRUE”, the order and sales platforms in the device management system 102 must be updated to realize the dynamic, data driven nature of the CT ecosystem. The CTs are stored in a cache or datastore maintained by the OS platforms (referred to as OS Cache). The OS Cache is available at a manufacturer (e.g., a device manufacturer 106) and maintained so that it does not have to depend on external services. This is to prevent manufacturing downtime and production outages. Also, for each supported software (or firmware) release for devices, version specific instances of CTs are created in the device database 104 (e.g., through mass migration), and the resulting definitions are pushed into the OS Cache.

[0056] FIG. 11 illustrates data and control flow in an implementation for CT updates, according to an embodiment. A user 1100 creates a CT (operation 1) using a configuration microservice (service) 1102. One or more records are created and stored in a database by the configuration microservice (operation 2). When the CT create operation is completed, then an event is sent to an event manager 1104 (operation 3). The event manager 1104 may be a Kafka platform. A datastore microservice (service) 1106 may be subscribed to one or more topics maintained by the event manager. The datastore microservice 1106 receives a notification of a new event and consumes the event from the event manager 1104 (operation 4). The CT is stored in a device configuration table 1108 accessible by the datastore microservice 1106. A readerdevice configuration parser 1110 may periodically access the device configuration table (e.g., every 30 minutes) and determine whether there are any unprocessed CTs to convert to object identifier (OID) and value pairings. If there are, then the reader device configuration parser 1110 converts the CT to OID / values (operation 5) and stores the results in an OID configuration table 1112. A datastore publisher microservice (service) 1114 may periodically access the OID configuration table 1112 (e.g., every 4 hours) and determine if there are any unprocessed OID entries. If there are, then the datastore publisher microservice 1114 reads them and transmits them to the OS Cache 1116 (operation 6). The reader device configuration parser 1110 (operation 5) and datastore publisher service 1114 (operation 6) actions may be asynchronously and scheduled to manage load, network availability, customer requests, or the like.

[0057] The format of the configuration’s identifier used by MMSA to push the configurations to the datastore cache is <Typed CT>-<CT>. The datastore uses same format to retrieve the configurations from its cache. For example, the datastore may use the identifier D001 READER-123456 to get the configurations of CT 123456 from its cache. With softwareversion variants (e.g., CT per software-versions) in place, MMSA continued to use this format and it was expected MMSA always pushes latest software-version variants to the datastore. Because software-version is not explicitly mentioned in the identifier, there can be issues if the latest software-version in MMSA and datastore are not same.

[0058] For example, if MMSA has Rl.1.2.3 as latest software-version but the datastore is not updated, it could have Rl .1.1.30 as latest version. In this situation, the datastore uses identifier D001 READER-123456 to get configuration compatible with software-version Rl.1.1.30 but the MMSA may have pushed a CT compatible with the Rl.1.2.3 version using same identifier. This situation may arise during final software verification review or a new software version release, when the MMSA has latest version and wanted to push them to a datastore but the datastore may continue to want to use previous version for provisioning the readers.

[0059] To avoid this issue, the identifier format can be changed to include the softwareversion attribute. A specific variant of CT can be pushed and retrieved from OS cache. With hardware model specific configurations, one more variations of configurations (CT) will be available. So, the identifier format can be changed to have software-version and hardwareversion in addition to device type and CT. The delimiter may also be selectively used to differentiate between different portions of the identifier format. For example, the current delimiter used in the identifier is dash (-) but because dash is used in hardware- ver si on and dot (.) is part of software version, a colon (:) can be used as delimiter. For example, the identifier format can be <Typed CT>:<CT>:<Software-version>:<Hardware-version>.

[0060] With so many variances, the MMSA may be better off pushing the configurations on demand instead of pushing everything to the datastore. CTs can be migrated to specific software or hardware versions on demand, such as when a work order or purchase order is received instead of creating / migrating CTs for all possible combinations of software and hardware version.

[0061] FIG. 12 illustrates data and control flow in an implementation for on-demand CT updates, according to an embodiment. With this approach, two services are used, one for creating a CT upon request and another one to push the configurations to the target datastore cache (e.g., OS Cache). It is understood that either new endpoints may be used on existing services (e.g., endpoints on the datastore microservice and the configuration microservice) or new microservices may be implemented instead of endpoints. Thus, although FIG. 12 refers to an on-demand publisher microservice 1200, it is understood that the functionality may be provided through an endpoint of the datastore microservice 1106. Using the on-demand publisher microservice 1200, a system (e.g., enterprise business services (EBS) 1202) or person can push a configuration to the target datastore cache (e.g., OS Cache) on demand.

[0062] A request is received at the on-demand publishing microservice 1200 from an enterprise business services (EBS) system 1202 (operation 1). The request includes a CT or other identifier (e.g., Structured Composite).

[0063] At operation 2, if the CT is available in the device configuration table 1108, then the corresponding OID / values are obtained from the OID configuration table 1112 and transmitted to the OS Cache 1116.

[0064] If, however, the CT is not available for requested software / hardware versions, then at operation 3, the on-demand publisher microservice invokes the configuration service 1102 to migrate the CT to the device configuration table 1108. The configuration service 1102 then operates on the CT as it would if the CT were created under the process described in FIG. 11, where the CT is created through migration, and the event manager 1104 is notified, and the CT is then stored in the device configuration table 1108 for the reader device configuration parser 1110 to operate on and store the OID / value in the OID configuration table 1112. At this point, the on-demand publisher service 1200 can transfer the OID / values to the OS Cache 1116. After completing its operation, the on-demand publisher service 1200 returns a status to the EBS 1202 (operation 4).

[0065] FIG. 13 illustrates data and control flow in another implementation for on-demand CT updates, according to an embodiment. In this second approach, parsing and pushing CTs to the datastore cache is performed by the configuration service 1102 itself. The configuration service1102 performs some of the functions of the datastore microservice 1106. As with the implementations discussed in FIG. 12, the additional functionality of the configuration service 1102 may be implemented as either a new microservice or as a new endpoint in the configuration service 1102.

[0066] A user 1100 creates a CT (operation 1) using a configuration microservice (service) 1102. One or more records are created and stored in a database by the configuration microservice (operation 2). When a work order is generated, the configuration microservice 1102 endpoint (or new microservice) is invoked to push the CT with a specific software / hardware version (operation 3). If the requested software or hardware version is not available, the configuration service 1102 can migrate it first as it has all necessary information before pushing the CT to the OS Cache (operation 4). After completing its operation, the configuration microservice 1102 endpoint (or new microservice) returns a status to the EBS 1202 (operation 5).CT Schema

[0067] CTs are arranged using a structured format (e.g., JSON, XML, BSON, etc.). This structured format may be referred to as a schema. In order to provide for device independence, key capabilities of CT processing, and management of the CT itself, the CT may be structured into a plurality of components, such as shown in the following data serialization format:{“metadata”: {},“initial configuration”: {},“substitute configuration”: {},}

[0068] The data serialization format data in the metadata clause of the CT includes various attributes to identify the CT, its provenance, version history, parent, common name, customer or owner names or identifications, creation, or modification timestamps, and the like. Information in the metadata clause is used in various processes of the device management system 102 to support ordering, manufacturing, shipping, updates, deployment, and other activities around the use and maintenance of a device.

[0069] The data serialization format data contained within the initial configuration clause of the CT is understood to contain information interpreted by device-specific processes. This section is colloquially referred to as the “Content” of the CT. It is referenced when determining if a user has access to a CT through the processing of content specific CT Access Rules. This isdescribed further below. Also, the content may contain references to key material that is securely stored in different keystores. When a key reference is to a custom key, the keyset tuple provides for the determination of which key store to use and the unique processing required to securely resolve the key reference.

[0070] The data serialization format data contained within the substitute configuration clause of the CT is processed by tools that comprehend that clause. It is used to dynamically augment a CT configuration by prompting for, or otherwise programmatically providing, values for the specified attributes.Example CT Metadata

[0071] Included here is a list of example metadata attributes that may exist in the metadata clause of a CT schema. These may be stored in the metadata document. It is understood that these are examples and that more or fewer may be included in any given instance of a CT.

[0072] “ CT identifier” may be a String value of a defined length, using any form of numeral encoding system and optionally may exclude certain alpha-numeric combinations that can be commonly confused, such as the letters “I”, “O”, “S”, and “Z” or numbers “1”, “0”, “5”, “2”. The CT identifier may optionally be sequentially allocated, and it may also be screened to eliminate accidental offensive or improper word spellings, such as by referencing a dictionary of excluded combinations. The ID may be used to reference the CT from the device database 104. This value can be determined by the CT Naming process.

[0073] “Typed CT” may be a String value representing the type information associated with a CT. CTs are wrappers that contain device specific template information. In order to properly process that content, each CT is typed. This allows the proper device specific toolchain to be invoked.

[0074] “ software version” may be a String value representing information about the software or firmware version. It is recognized that each supported device type has software (or firmware) associated with it, and that software and firmware will evolve over time resulting in many supported releases that must be comprehended. The software version attribute also provides a reference for the versioning and migration of CT content, as that content can be unique to each supported release.

[0075] “parent” may be a String value to represent a hierarchical relationship to another CT, and can be null. CTs support an arbitrary deep system of inheritance and hierarchy. Not all CTs use this as a “Variance” CT may contain only specific configuration attributes of interest that have varied. The CTs are managed in alignment with how devices are manufactured and providefor an ease of specification where one need only specify a subset of attributes of interest that differ from another CT. The device independent inheritance capabilities and Initialization CT support rely on this attribute.

[0076] “New Initialization CT” may be a String value representing a new CT, and it can also be null. The versioning and migration of CT content, when processed, results in a new version of the Initialization CT that serves as the root of inheritance. This new root is stored in the New Initialization CT attribute to facilitate a direct lookup into the device database 104.

[0077] “name” may be a String value to provide for a user-friendly name to be specified. This value can be whatever the owner of the CT decides, and it can be updated regardless of the lifecycle state of the CT.

[0078] “ comments” may be a String value to provide additional optional commentary on the usage, pedigree, purpose, change history, provenance, etc. to be documented as part of the CT itself.

[0079] “internalcomments” may be a String value to provide internal maintenance commentary to be maintained separately from customer / user specific commentary fields in the comments attribute.

[0080] “licensing” may be a String value to reference the remote terminal unit and provide details on which licenses are applicable, the terms of the license, etc.

[0081] “ available” may be a Boolean value that indicates whether the associated product configuration is available for purchase. CTs that inherit, either directly or indirectly, from the Initialization CT, and are in the Published status of the CT lifecycle, can be marked as available. These CTs are then available when creating custom configured devices in distribution centers 108. Setting the available attribute to TRUE also triggers an on-demand population of the manufacturing datastore and other backend system processing.

[0082] “ status” may be an Enumerated type with various values, such as Draft, Publishable,Published, Deactivated, etc. to denote what can or cannot be done with a CT. For example, this field permits CTs to be created and edited freely (Draft state); locked to permit, of times remote, testing of the configuration the CT contains (Publishable state); placing the CT into production usage which prevents further change (Published state); and when necessary, removed from use when it has been replaced with another configuration or is no longer wanted (Deactivated state).

[0083] “ customerld” may be an Integer value representing information associated uniquely with a customer. This documents the owner of the CT and provides for a basic authorization mechanism. Additionally, the customerld may take one of a plurality of system reserved values which can lock or modify accessibility and modifiability of the CT, based on content specificaccess rules. Specific delegated authority rules can also be specified for a CT that override this basic authorization mechanism.

[0084] “ acct” may be an Integer value that is provides specific CTs associations with corresponding customer accounts (e.g., those created via a substitute configuration mechanism). The acct attribute documents the customer account ID when that is the case.

[0085] “Quick reference” may be a String value associated with the set of attributes for simplified customer retrieval. The user interface in the device management system 102 supports a defined set of attributes that have been deemed to be of particular interest to customers. When a specific customer configuration is created that contains a specific attribute of interest to the customer that is not included in the automatically generated string, any text contained in this attribute is appended. This permits easy extensibility to handle one-off conditions.

[0086] “history” fields may be one or more String values used to document the user identity that created the CT or performed other actions, including timestamp data, for audit and traceability purposes. In an embodiment, all changes to a CT are maintained and can be accessed by internal users with sufficient privilege for complete traceability support. Changes to the CT may be available in one or more repositories. More recent changes to the CT may be stored in the metadata for easier reference. Different types of actions may be separately stored and organized under their respectively associated category of history field.

[0087] “isVisible” may be a Boolean value that Determines if the CT is returned for global search queries, subject to the application of read access rules.CT Inheritance

[0088] A CT contains an initial configuration clause in its data serialization format structure that holds a template describing a baseline or backing device configuration. The CTs metadata clause also supports the specification of a parent CT using the attribute “parent” as described above. This provides the basis for a device independent inheritance chain of arbitrary depth. The semantic meaning of the data serialization format object contained in the initial configuration clause is unknown to the system that processes CTs; however, by using the parent attribute, all processing is data driven by each parent value tuple in each CT up to the CT identified in the initial configuration clause (e.g., the root, baseline, or backing CT).

[0089] CTs support an inheritance structure that enables a base definition, the Initialization CT, which documents the state of a device as it was originally created, before any unique configurations are applied. For smartcard readers, this is how it leaves the device manufacturer 106. The Initialization CT is the configuration used if a customer 110 orders an Off-the-Shelf(OTS) smartcard reader device. CTs can be referenced without processing the inheritance chain, or with a full “walk” of that chain. When provisioned at the distribution center 108, a full walk of the inheritance chain is always performed.

[0090] The schema that determines how the data is properly structured and parsed is independent of instances of data that align with the schema definitions. The method of inheritance works without any reference to the schema at all, it is purely data driven. This permits the full capability of inheritance to be supported for all device types.

[0091] While arbitrary levels of inheritance are supported, most CTs are defined with a relatively short inheritance chain, for instance with the Initialization CT having a large amount of shared configuration details and the child having a customer specific customization. In FIG. 2, three types of inheritance are shown: 1) Simple inheritance where a CT references the Initialization CT and changes selected attributes; 2) Simple inheritance where a CT references the Initialization CT and changes selected attributes while also defining an incomplete CT (e.g., not all required attributes have values); and 3) Inheritance through an incomplete CT where the required attributes (those with a null value in the substitute configuration) are specified. FIG. 3 illustrates the values used after resolving the inheritance chain for the CTs 1234F1 and 1234F2. Unless a substitute configuration itself is complete, it is ignored when inheritance is processed (i.e., only an initial configuration is constructed).

[0092] A CT inheritance chain supports an arbitrary depth of inheritance. As discussed above, the root of that inheritance chain defines a template configuration that matches how the managed device is produced in the factory. This specific CT is referred to as the Initialization CT. This addresses two needs. First, it provides the basis of a digital twin as the configuration stored in the repository matches the configuration of the device. A digital twin is a digital representation of a physical instance of a device. Second, the Initialization CT simplifies customizations as any “child” CT that inherits from the Initialization CT need only specify revisions from the Initialization CT.

[0093] The Initialization CT, when referenced directly or indirectly, permits a CT to be marked as available. Only CTs that specify the full configuration surface of a smartcard device reader for the desired configuration are produced at the factory in order to ensure correctness.

[0094] Each release of firmware may result in the need to update the Initialization CT. Sometimes there is no schema difference, and a change to the Initialization CT is not required. The Initialization CT is associated with the device as it is configured when it leaves the device manufacturer 106 and forms the base for inheritance. The Initialization CT, like other CTs, may be versioned.

[0095] The basic inheritance chain may also be augmented to accommodate differences for hardware families. Classes of devices may require different initial configurations to properly establish their Initialization CT. This mechanism registers a Physical Initialization CT within based on the device type. When a device version is referenced, the normal inheritance chain is augmented by the insertion of the Physical Initialization CT after the Initialization CT and before the first child CT. This provides different base hardware configurations for device families. For instance, a device may have a different default color (e.g., blue) instead of the normal default (e.g., red).

[0096] Hardware model and version specific configurations can be applied to a Physical Initialization CT, similar to a SW / FW Initialization CT. The Initialization CT defines default configurations for software versions. Following this approach, a CT that defines hardware specific configurations can be used in same way as Initialization CT is used for software versions. This CT containing hardware version specific configurations whenever inherited by other CTs, will provide hardware version specific configurations to them. The Hardware Initialization CT defines default configurations for specific hardware versions.

[0097] Both the Initialization CT and the Physical Initialization CT conform to same reader device configuration schema. In doing so, they both evolve together. Where migration is needed for an Initialization CT (plus all inheriting CTs) whenever a reader device configuration schema changes, a migration is also applied to any Physical Initialization CTs. When complete configuration for a hardware version is requested, Physical Initialization CT is inserted in the inheritance chain after the (software) Initialization CT to add hardware version specific configurations to the complete CT. This way, based on given hardware versions, a complete CT will have different configurations. If hardware version is not provided, the complete CT returned will not contain any hardware specific configurations.

[0098] FIG. 4 illustrates control and data flow of an Initialization CT, according to an embodiment. When a CT is requested, configuration of just that CT alone (corresponding to the API parameter “software-version” if specified or latest software release if not specified) is returned. But when a CT is requested with the complete configuration operator, configuration of the CT along with configuration of its inherited CTs (e.g., parents) all the way up to Initialization CT are fetched. FIG. 4 shows this inheritance chain. Based on the software version used (which indirectly refers the reader device configuration schema version), a complete configuration returned may vary. If the software version is R1.1.1.31, for example, the inheritance chain under schema vl.2 is used for complete configuration. For software version Rl.1.2.3, the inheritance chain under schema version v2.0 is used. FIG. 5 is a table ofmicroservice application programming interface (API) parameters, according to an embodiment. The parameters may be used in RESTful API.

[0099] Microservice API calls are a key mechanism used in microservices architecture, where individual services communicate with each other to perform tasks. In this architecture, an application is decomposed into small, independently deployable services, each responsible for a specific functionality (e.g., user authentication, payment processing, inventory management).These services typically interact using lightweight protocols like HTTP, and the interactions are made via APIs (Application Programming Interfaces).

[0100] When one microservice needs to request data or trigger an action in another microservice, it makes an API call. This call usually involves sending a request over a network (often using REST, gRPC, or GraphQL) to an endpoint exposed by the target microservice. The request typically includes parameters or data (e.g., in JSON format), and the target microservice processes it and responds with the requested data or acknowledgment. These interactions can be synchronous (where the calling service waits for a response) or asynchronous (where the calling service continues its operations and processes the response when it arrives).

[0101] In practice, microservice API calls allow services to communicate without tight coupling, enabling each service to be developed, deployed, and scaled independently. This flexibility helps improve resilience, as a failure in one microservice does not bring down the entire system, and it enhances scalability by allowing services to scale according to their specific needs. However, microservice API calls can introduce challenges related to network latency, error handling, and the need for more sophisticated monitoring and security practices.

[0102] RESTful refers to an architectural style for designing networked applications and APIs based on the principles of REST (Representational State Transfer). RESTful APIs use standard HTTP methods to perform operations on resources, such as creating, reading, updating, or deleting data. The term “RESTful” is often used to describe APIs that adhere to REST principles, offering a stateless, scalable, and uniform approach to communication between clients and servers.

[0103] FIG. 4 illustrates the migration used whenever new software version is released. Usually, a new Initialization CT is created whenever a new software version is released. For that software version, all of the CTs inherit the newly created Initialization CT. Because there is a change in the reader device configuration schema for the new software version, the CTs should get updated to conform to the new schema. Instead of updating the existing CTs, new versions of CTs are created with updated content to conform to the new schema (and the new Initialization CT), when their content requires. This process is referred to as migration. Existing CTs aremigrated to the new Initialization CT and schema. After migration, configuration related to older the software version can also be retrieved by specifying the software version in the request (API call).

[0104] With the addition of a Physical Initialization CT, both software and hardware attributes are baselined. FIG. 6 illustrates control and data flow of a Physical Initialization CT, according to an embodiment. The flow in FIG. 6 flow takes effect only when a hardware version is requested in the complete CT API call using the “hardware-version” parameter. If hardwareversion is not specified, then the API complete CT call returns results similar to what is returned in FIG. 4. Hardware version specific configurations using Physical Initialization CT are inserted after (software) Initialization CT in the inheritance chain so that the configurations specific to hardware-version can overwrite the default configurations. Similarly, variance CT inheriting the Initialization CT can have configurations which can overwrite the configurations defined in both Initialization CT and Physical Initialization CT. Both Initialization CT and Physical Initialization CT are used to define default configurations for particular software and hardware versions, respectively, and if required those default configurations can be overwritten in variance CT. FIG. 7 is a table of microservice application programming interface (API) parameters, according to an embodiment.

[0105] Whenever a reader device configuration schema is changed, Physical Initialization CTs are migrated so that they can conform to changes in the reader device configuration schema. The reader device configuration schema is changed as part of a software version release, so it is linked to the “software-version” parameter. Below is an example of software versions and corresponding schema versions.

[0106] When a complete CT is requested with the hardware- ver si on parameter, which version of Physical Initialization CT to be used in the inheritance chain is decided based on the software version as schema versions are indirectly referenced through software-version. For example, if CT 1234F1 is requested with hardware-version RD01-L00-YYYYYY A and software version R1.1.1.31, then hardware Initialization CT YYYYYY in the column corresponding to reader device configuration schema vl.2 will be used in the inheritance chain. This is decided based onthe given software- ver si on R1.1.1.31.

[0107] In addition to hardware- ver si on, the Physical Initialization CT can be linked to a hardware family. The hardware family contains groups of hardware versions e.g., one or more hardware versions. For example, RD01 can be hardware family for RD01-L00-YYYYYY A and RD01-L00-YYYYYY B; and RD02for RD02-L00-YYYYYY A and RD02-L00- YYYYYY B versions. This means the Physical Initialization CT linked to a hardware family segment is applicable for all the hardware versions under the hardware family segment. A hardware family’s parent is used only when the given hardware-version does not have any Physical Initialization CT.

[0108] For example, assume we have a hardware version RD02-L00-YYYYYY B with no Physical Initialization CT associated but it is under the hardware family RD02which has PPPP01 Physical Initialization CT. When a complete CT is requested with version RD02-L00- YYYYYY B, the Physical Initialization CT PPPP01 associated with hardware family RD02is used in the inheritance chain. This is because hardware version RD02-L00-YYYYYY B does not have a Physical Initialization CT, so its family’s Physical Initialization CT is used.

[0109] When requesting for complete configuration, instead of hardware- ver si on, hardwarefamily can also be specified like / configuration / 1234Fl / hardware-version / RD02. Here Physical Initialization CT associated with hardware family RD02will be used in inheritance chain.

[0110] For instance, the parameters “ / configuration / 1234Fl / hardware-version / RD02 / complete” return a configuration of CT 1234F1 including the attributes of its parent, configurations of the Physical Initialization CT of RD02 , and configuration of the latest software version’s Initialization CT.

[0111] To bring in the concept of Physical Initialization CT and hardware family, changes in device type entity are implemented. Device type entity has hardware versions as a list with a version attribute specifying hardware versions. Two more attributes are added to facilitate the use of a hardware family:“hardware-comm on -parent” : To associate a hardware version to a hardware Initialization CT; and“family” : To associate hardware family to the hardware version.

[0112] FIG. 8 illustrates device versioning clauses in a CT, according to embodiments.CT Migration and Versionins

[0113] As discussed above, the use of an Initialization CT or Physical Initialization CT may result in a group of CTs migrating to a New Initialization CT. Device Specific Toolchainsprovide a mechanism to support both backward (via convention primarily) and forward compatibility for CTs. This is necessary as each software / firmware release introduces changes in functionality and / or configuration specifications that must be accommodated without requiring all CTs for those devices that were created for an earlier version of the software to be recreated.

[0114] Device Specific Toolchains, in cooperation with management microservices architecture (MMSA) services, provide a mechanism to support both backward (via convention primarily) and forward compatibility for CTs. This is necessary as each software / firmware release introduces changes in functionality or configuration specifications that must be accommodated without requiring all CTs for those devices that were created for an earlier version of the software to be recreated. These “migration rules” and the associated processing (both via dynamic reference and in a bulk processes intended to prepare a large number of CTs for immediate access within the new release environment) accomplish the desired transformations.

[0115] Migration rules are specified for each supported type of data transformation including: a. Addition - previously unspecified capabilities that are now part of the default configuration for the release b. Deletion - a previously specified capability that has been deprecated and is removed from the default configurations c. Change in Value - an existing capability whose value must be changed d. Change in Type&Value - an existing capability that was described as one type (such as an integer value) and is not specified as another type (such as an enumerated type) along with the new default value consistent with the new type e. Structural Change - an existing capability that was contained in one portion of the schema that has been moved to another portion of the schema; this type of transformation is often accompanied by a Change in Value or a Change in Type&Value f. Others are added as the need for new transformations in encountered.

[0116] The migration rules can be specified in a generic way that applies to all stored CTs regardless of their type, or as a feature of the device configuration associated with a specific device type, or as a combination of both as it is often the case that a generic rule is not always sufficient to address the required transformation because of a unique property only understood in the context of a specific device type.

[0117] Migration is supported via two major mechanisms: 1) The description of rules (e.g., new additions, modifications to existing values, movement and / or renaming of an attribute,deletion of the attribute) that permit existing CT content to be automatically altered for each release (this is termed “Migration”); and 2) Support in the CT metadata and API that allows for explicit references to a SW version that has been registered and can obtain the desired version of the configuration template.

[0118] CTs can be migrated when required on reference. This task can take unwanted processing time. Instead, a mass migration may be done of all Published and available=TRUE CTs as part of the preparation to release a new SW version into production.

[0119] FIGS. 10A-B illustrate a flowchart of a process for posting a configuration with a particular software version, according to an embodiment. For each CT that has been PUBLISHED (decision 1000), the system determines if there is a new software version available (decision 1002). If there is not a new software version available, no further processing is required, and the process exits. The schema details for the new software version are referenced (operation 1004) and the system determines if this is a major change (one where migration processing is required) or a minor change (decision 1006).

[0120] If no migration is required, the inheritance chain is walked (e.g., parent configurations are pulled until the end of the chain is reached) (operations 1008 and 1010) and the fully composed configuration is produced (operation 1012). If a migration is required, then after the inheritance chain is walked (operations 1014 and 1016) the migration rules associated with the new schema are exercised (operation 1018) thus transforming the configuration as required. In either case, the fully composed configuration is parsed to produce the OIDs and is loaded into the OS datastore (operation 1020).Substitute Configurations

[0121] Part numbers are defined in the device management system 102 that specify a configuration and “leave space” for the specification of a customer specific value. With CTs, a substitute configuration can be specified that allows for the dynamic specification of attribute values. This mechanism is used for incomplete CTs to support the triggering of user interface screens and subsequent processing to complete the CT. A similar mechanism is used in the configuration management tools to support the dynamic prompting of the required values from the user at the time the CT is processed.

[0122] An example of a substitute configuration clause follows. When processed each null reference must be resolved by the processing tool. The resulting resolutions are placed in a new CT that is created with an appropriate initial configuration clause. That CT can, in turn, point to the CT that contained the substitute configuration clause as its parent. This permits thedynamically determined configuration to be used to actually configure a device, and also to be kept ensuring the digital twin is an accurate reflection of a device’s configuration.

[0123] A substitute configuration clause may be used at the time of application of the CT to the device. One use case is at the time one orders a reader. In this situation, the processing creates a custom CT with the provided attributes, which is added at the end of the inheritance chain. Then, later during manufacture, the manufacturing process references this in the work order used to physically provision the device.

[0124] This is also used “in the field” to support the same type of configuration flexibility described above. An “off the shelf’ device may be shipped and then later customized as part of a multi-tier distribution ecosystem outside of the factories. This type of post-manufacture configuration may be used all the way to the end user if they desire.

[0125] The substitute configuration mechanism is general purpose. End users can use the same mechanism to provide for “families” of configurations that differ in whatever attributes they desire to specify at the time the configuration event is performed.

[0126] FIG. 9 is a data serialization format formatted text block that illustrates a substitute configuration, according to an embodiment. By using the substitute configuration clause, tools can complete processing without any semantic knowledge of device template. The schema associated with the device specific Toolchain associated with the CT type ensures correctness of the inserted values.

[0127] The substitute configuration is a clause stored in the configuration description document in the device database 104.

[0128] “ software version” may be a String value representing the software version associated with the CT when created. The software version is a release of the associated software (or firmware) that contains a given set of capabilities. As software is developed, it usually grows in capability and will also change to correct undesired behaviors: fix bugs, alter defaults, improve performance. The CT describes the configurable aspects of a managed device, and not all changes to the software for a device change those configurable aspects. When those configurable aspects do change, those changes result in a new schema version being created that captures the changes.

[0129] “ schema version”: (String) A version of the schema that was used when the CT was created. As described above, a given schema version can be associated with multiple software versions. The introduction of a new schema version is associated with CT Versioning.

[0130] “initial configuration” may be a map object representing the main content of the CT. This is where, for smartcard reader devices, the reader device configuration document resides,which may be of a particular data serialization format such as YAML, BSON, MessagePack, JSON, XML, etc.

[0131] “ substitute configuration” may be a map object representing a secondary content document that is a proper subset of the initial configuration schema. The attribute values in substitute configuration replace those in the initial configuration. Also supports the mechanism that identifies an Incomplete CT; one where attributes have a null value. Clients that apply the CT are responsible for resolving the unspecified values prior to application. Inheritance is used to specify those values.

[0132] Various “Hash” fields may be a string value used in DeDuplication detection.

[0133] “ substitution complete” may be a Boolean value that specifies if the content of the substitute configuration is complete (e.g., contains no null values) and does not require processing by clients prior to application of the CT.Digital Twin

[0134] Each CT applied to a device (including the Initialization CT that matches how it was created in the factory) is recorded in device history records. Updating the history provides a digital twin that can be used for support, data analysis and reporting, and determination if preconditions are met for a desired configuration operation.

[0135] All tools in the ecosystem contribute by ensuring the history is updated when required and is accurate: e.g., manufacturing systems (to document the configuration of the device as it leaves the factory), distribution centers, on-prem databases, technical support databases, and programming devices when performing updates to a device.

[0136] In an embodiment, new CTs are generated from a reader device’s inspection logs. The OID values read from a device may be used to look up CTs. When an inspection log is generated, the UUID of the device is logged, OIDs are gathered, and timestamp information is obtained for when a value for an OID was applied. Additionally, the current firmware version of the reader device is stored to determine the reader device configuration schema to be used while creating CT.Using the device configuration sequence to Manage CTs

[0137] CTs are device independent and must support processing templates from their description (a data serialization format object that follows a specific schema to ensure correctness) into a device language that can be used to actually configure a targeted device. A variety of tools (referred to as toolchains) may be used to manage CTs. The configuration schema may be applied to devices other than readers, such as credentials, controllers, encoders,etc.

[0138] The reader device configuration sequence contains the schema that allows new templates to be verified as correct before a CT can be created that contains them. The processing of the template into device specific instructions (e.g., parsing) and the resolution of key material referenced from the specification from secure keystores.

[0139] The reader device configuration sequence provides common logic for preparing a configuration payload, which can be used to configure the reader devices in different use cases. The reader device configuration sequence is configured to convert CTs to object ID (OID) values including configurations and keys, and encrypt the OID values for the reader using given UUTD / engine ID.

[0140] The reader device configuration sequence uses an embedded parser to convert the CT content to OID values in the device management system 102. For encrypting them, the device management system 102 may use a microservice. Because converting CT to OID values and encrypting them is computationally expensive and cannot be completed in synchronous call, the parsing process is implemented as asynchronous call.

[0141] An API in device management system 102 is used to accept the request for configuration from a device management application and provide a link to get the configuration later asynchronously after it is ready. In other implementations, a messaging system is used to place requests. The device management system 102 can pick the request, process it, and place the response in the messaging system from where the requester can pull the response.

[0142] Converting a CT into reader device commands involves the following steps. First, a Request Validations operation is used to validate a request. The Request Validations operation is synchronous, meaning the requestor receives a response immediately whether there is any error in the request, or the request is accepted for processing. Other operations are asynchronous.

[0143] These operations are submitted as tasks to a pool and based on available threads (e.g., CPU, VM, etc.), they get picked, processed, and put back to the pool until all operations are completed for a request. Processed requests with converted commands are available in a configuration service for a preconfigured time (e.g., 24 hours), and the requestor can get it using the request ID any time they want within that time. After the preconfigured time (e.g., 24 hours), request details including the converted reader commands are removed from the database.Eviction processes may be used to maintain a fresh cache.

[0144] A reader device configuration parser tool is used to convert a reader device configuration template to an OID / Value format understandable by a device. A reader device configuration file may be mapped to OIDs configuration values using an OIDs Definition file.The reader device configuration parser tool takes as input a reader device configuration template (or specific option key / value directly) as input, or optionally reader device configuration schema, OIDs Definition, Keys Definition as additional inputs, and if undefined it uses latest version.The tool outputs output OIDs / Values and may optionally output in different file formats (e.g., JSON, XML).Keystore Types and Keystore Abstraction

[0145] Network management systems can use SNMP (Simple Network Management Protocol) to monitor network-attached devices for conditions that require administrative attention. In SNMP, an OID (Object Identifier) key is a globally unique identifier used to specify a particular variable or resource on a network device that can be managed or monitored. OIDs are structured in a hierarchical tree format, where each node represents a resource or object that can be managed via SNMP. These objects can include information like device status, network statistics, or configuration settings.

[0146] An OID key consists of a series of integers separated by dots (e.g., 1.3.6.1.2.1.1.1), with each integer representing a node in the hierarchy. The hierarchy starts with the root, governed by international standards organizations, and branches out to various sub-trees representing different device vendors, standards, and managed objects. The OID points to a specific piece of information or parameter within an SNMP-enabled device, such as a router, switch, or printer. By querying an OID, network management software can retrieve data like uptime, memory usage, or interface statistics, allowing administrators to monitor and manage devices remotely.

[0147] The OID keys used on credentials (e.g., smartcards) and in readers (e.g., for credential support and the original equipment manufacturer (OEM) SNMP keys) can reside in many different places. The term key space is used to refer to each of these separate domains. These places include OEM databases, on-prem databases, cloud database, partner database, etc. The keyspaces may be federated (e.g., in a single logical operation one can reference key material from multiple domains in a relative manner, not just with absolute references).Key store Types and the Keyset Abstraction

[0148] Manufacturer keystores may be rooted in managed namespace registries and be controlled by the manufacturer to generally contain manufacturer-specific key material. One can also inject a custom key value into this space by associating it with a unique customer-associated value.

[0149] Similarly, customer keystores offer a new capability to support customer specific namespaces. These may be rooted in managed namespace registries and generally contain customer-specific key material. These are established through an on-boarding operation where each customer receives a unique identifier. There can be many independent customer namespaces. Keys that reside in a customer namespace may be, by definition, custom keys.

[0150] The central server key stores support secure and managed key stores that reside on the central server. There can be as many of these as the user wants; each one is uniquely named and accessed. Additional keystores may be established to support specific types of devices, such as encoders and secure access modules. Certain keystores may be designated as a source for keys to import into other high-security keystores, such as from one secure access module to another or from a secure access module to an encoder device. Additionally, one or more keys may be grouped into one or more sets, and access to a key stored within a keystore may be restricted to referencing the set in which it belongs.

[0151] In an on-prem installation, the central server may be a customer central server (e.g., customer central server 1906), which is installed on-premises at a customer’s location and may be isolated from external networks (e.g., isolated from the Internet).OID Mapping

[0152] When specifying a Keyset tuple for certain key types, it may sometimes be necessary to provide for a mapping between the keystore where the keys where originally created, and a keystore the keys are securely copied into for other uses. As each Keystore maintains its own OID references, this allows the mapping from the source keystore's OID structure into the destination keystore's OID structure.Key store Domains and Instances

[0153] Each Keystore Type exists in a specific Domain. Sometimes there is only one Domain that a keystore can be associated with (such as a manufacturer’s owned namespace). For other keystore types there are keystores that can exist in different Domains. In those instances, there is a need to specify the Domain associated with the desired keystore, as well as which specific instance of the key store type we wish to reference within that Domain. These two attributes support both absolute and relative references. An Absolute reference unambiguously specifies exactly one Domain or Keystore Instance within a Domain. A Relative Reference specifies a search order that is used to identify a specific Domain or Keystore Instance within a Domain.

[0154] Relative reference to Domains may be supported via the central server. On-premisessystems may also be configured such that each of its clients is associated with one and only one physical Server. That connection is captured in a server gateway, and is referred to as the client’s central server. Cloud-based systems may also be configured such that each of its clients is associated with one and only one client organization platform. That association is captured in a server gateway, and is referred to as the client’s central server. Mobile applications may be associated with either an on-premises system server when running in offline mode, or both an on-premises system Server and a cloud-based system Server when running in online mode. Key management service can also be established as its own central server (standalone configuration) or can be associated with an on-premises system Server via a server gateway.

[0155] A keystore tuple associated with a domain can include any mix of relative or absolute references. For example, a tuple referencing an absolute domain and an absolute keystore refers to one and only one Keystore. If that Keystore does not exist, then the reference fails, and the CT cannot be resolved. Additionally, if the Keystore does not contain the specified Keyset, then the reference fails, and the CT cannot be resolved.

[0156] Similarly, a tuple referencing a relative domain but an absolute keystore refers to a specific instance of a Keystore that resides within a Domain that is accessible from the specific client on which the CT is being resolved. The specific client is checked and if that client holds the desired Key store Instance then it is used. If the specific client is associated with a central server, then that central server is checked. If it holds the desired Keystore Instance, then it is used. If the specified key store is not found at this point, then the relative reference fails, and the CT cannot be resolved. Additionally, if the specified keystore is found, and it does not contain the specified Keyset, then the reference fails, and the CT cannot be resolved.

[0157] Similarly, when a tuple references an absolute domain but a relative keystore, the specified Domain is checked to determine if it contains an instance of the specified Keystore Type. If that Key store type is present, then it is used. If the Domain contains more than one instance of that Key store Type, then the instance identified as the “default” is used. If that Keystore type in not present (or the default is not present / specified), then the reference fails, and the CT cannot be resolved. If the chosen Key store Instance does not contain the specified Keyset, then the reference fails, and the CT cannot be resolved.

[0158] Finally, when a tuple references a relative domain and a relative keystore, the specific client is checked. If that client contains a Key store of the desired type, then it is used. If the Client contains more than one instance of that Key store Type, then the instance identified as the “default” is used. If the specific client is associated with a central server, then that central server is checked to determine if it contains an instance of the specified Key store Type. If that Key storetype is present, then it is used. If the central server contains more than one instance of that Key store Type, then the instance identified as the “default” is used. If that Key store type in not present (or the default is not present / specified), then the reference fails, and the CT cannot be resolved. If the chosen Keystore Instance does not contain the specified Keyset, then the reference fails, and the CT cannot be resolved

[0159] In order to properly configure devices and the data objects (e.g., a physical credential on a plastic card) they support, there are a plethora of keys that need to be managed and accessed for each configuration event. These keys may exist in different domains: centrally managed Key Stores used by a vendor, Customer Specific Key Stores maintained on behalf of a customer, Device resident Key Stores that are hardware supported (such as those kept on a physical device such as a hardware security module (HSM), a secure access module (SAM), or Credential Encoders), site specific Key Stores maintained in secure database / repositories resident in service provider, or customer environments, including cloud based software-based HSMs offered by cloud service providers.

[0160] Previous approaches required individual tools and manual tasks uniquely associated with each type of Key store that acted in isolation from others that only worked within a single domain. This manual approach is tedious and error prone.

[0161] The Keystore Tuple provides for a common, extensible method to access all required keystores regardless of where they physically or logically exist. It permits a CT that describes a configuration event for adding or modifying keys on a managed device, such as an access control reader, to reference an arbitrary number of keys from an arbitrary number of different keystores. It does so by defining both absolute and relative location information for each set of Keys (called a Keyset) that are associated with a Credential, Media type, or other secured data object (Keys often come in groups rather than just a single Key). And provides for late binding as the configuration template is processed so that at each step within the Federated Keyspace the Keyset references contained in the current domain in a serialized “walk” through required domains can be resolved before moving on to the next step in that walk.

[0162] When an OID key is referenced in a CT, a Keyset Abstraction is used. Each Keyset can reside in any supported Keystore (sometimes, more than one). So, what is needed is a way to unambiguously identify which Keystore the Keyset resides in. The Keyset Tuple provides that mechanism. The tuple is referenced within the CT for each referenced keyset. Many different key stores may be referenced from a single CT. The operation of Resolving the key store reference is used to determine which Keystore to reference for a reference in the CT. This resolution occurs when the CT is parsed.

[0163] Keystore Type is an enumerated type and may take on various values according to the keystores that are supported.

[0164] Key store Domain is a string and may include the address or description of the domain. Supported values depend on the associated Keystore Type. The Keystore Domain may be null when there is no supported domain. When Keystore Domain is null, a relative reference is used to resolve the domain from the Keystore Type.

[0165] Keystore Instance is a string and includes supported values depend on the associated Keystore Type. The Keystore Instance may be null when there are no supported instances in a domain or type. When Keystore Instance is null, it is resolved to a reference to the default grouping of “Standard.”

[0166] The Keyset Name is a string that typically should be unique within the keystore.Keysets are typed and can hold multiple individual keys of variable lengths to properly support the targeted technology or use.

[0167] The OID Mapping is a string and is the OID value to substitute for the secure delivery infrastructure OID as described above. The OID Mapping may be null.

[0168] The contents of a CT can determine who has access to the CT. This access control is beyond other methods that regulate access via access control lists based on the user or the organization associated with users. The protected content includes OID key references.

[0169] Each Keystore may support access control so only approved users can gain access to the key material they store and protect. Access to classes of keys may be controlled via delegated authority mechanisms.

[0170] In an example, embodiment, all members of an organization are granted read access and admins of the organization have write access. Those with read access may also be granted access to read custom keystores. A delegated authority mechanism may be used to provide granular access permissions. Keystores may be protected by a password that must be entered to gain access to its contents. In an embodiment, the owner of a keystore is the only one that can alter the keystore contents.Firmware Installation File Construction

[0171] This section details the enhancements to generate reader-specific 1 -file firmware to upgrade a reader device. This is an MMSA capability required to support the creating of reader device firmware 1 -files as binary blobs that must be unique for each individual target device. Various tools may use this service. Their request patterns, how the service generates readerspecific firmware file, its service interfaces with other services, the potential load it needs tosupport, the service detailed design to meet this load and other requirements, how the service can be implemented, and a few other aspects are discussed further here.

[0172] In some implementations, this service hosts generic (non-reader-specific) files needed to upgrade readers. In the improved implementations, instead of multiple files, a single file is generated. For backward compatibility, tools can use existing microservice endpoints to generate the multiple files used for upgrading readers to the FW release that requires these specific 1-file firmware file, and then use new endpoints to generate and obtain a reader-specific 1-file firmware for upgrading readers to versions beyond that point.

[0173] There are the three different ways in which tools can request reader specific firmware file(s) from this service. In a first implementation, for an app that can work with only one reader at a time it will always request firmware file for a single reader.

[0174] In a second implementation, tools can have multiple readers connected to them simultaneously and can upgrade firmware to those readers concurrently. Therefore, these tools can request firmware files for multiple readers in a single request. Additionally, these tools can begin upgrading a reader as soon as its firmware file is ready, without having to wait for firmware files to be generated for all readers in the request. This allows for immediate upgrading of each reader as firmware becomes available, streamlining the upgrade process.

[0175] In a third implementation, this service can also be used for readers in the field which are not directly connected to tools but are connected through third-party controllers. For such readers, customer can collect reader details through third-party controllers or some other means and place a request to this firmware service either by providing the reader details in the request body or by uploading a data serialization format file containing all reader details. Once the firmware files are generated from this service, the customer can download them, move them to the required locations, and apply them to the readers. The specifics of moving and applying the firmware files are out of scope for this topic but what they need is a way to get firmware for multiple readers in a single operation. Customers may not prefer to download the files one at a time; instead, it would be easier for them to download and copy if the firmware files for all requested readers are bundled / zipped into a single archive. Also, a cloud portal can be used as a UI for a customer to upload the input data serialization format file containing all their reader details and once firmware files are generated, they can simply download files from the cloud portal for all readers as a single zip file.

[0176] To support these request implementations, the service is designed to be flexible. The service can accept requests for single or multiple readers. Reader details can be provided in the request body or uploaded as a data serialization format file. Generated firmware files can bedownloaded individually one by one or combined as a single zip file. When firmware is requested to be available individually rather than as a single zip file, each firmware file is made downloadable as soon as it is ready, without waiting for the generation of firmware for all remaining requested readers. To keep a requestor informed, the service can provide an endpoint that reports the current status of a firmware generation task. For multiple readers request, the service can provide details on how many readers are completed and how many are pending. If firmware generation fails for one or more readers, the service can offer reader-specific details explaining why the firmware generation failed.

[0177] The following details the process for a specific device type and what is required to properly update the FW for several integrated circuits (ICs) in the device. All of the required FW images are created as required for the target device and combined into one file that is itself described by a data serialization formatted manifest. References to the SNMP messages spec to device specific code that must be generated. Secure Delivery Infrastructure (SDI) is a reference to a central set of key management and encryption services. The Key Management Service (KMS) is one such service.

[0178] To generate the reader specific 1 -file firmware, the following operations may be performed. Operation 1 : Input for 1-file firmware generation is ‘reader-info’ details fetched from the reader. These details are required for generating the 1-file firmware.

[0179] Operation 2: Reader’s data received in the request is validated against the data already available in ODM device repository. This includes, but is not limited to, the following validations: 1) validate whether requestor has access to upgrade the reader based on the requestor and owner information available in the repo; and 2) validate whether requested reader has pending operation like firmware upgrade, configuration change requested but not updated back.

[0180] Operation 3 : The next step is to look up the manifest and start preparing a firmware payload for each target. The firmware payload needs to be generated for each target based on the “generation type” defined in the manifest. The firmware payload for a primary SAM target is generated.

[0181] Operation 4: The firmware service invokes SDI to generate an SNMP loader message by providing the reader’s username and engine Id.

[0182] Operation 5: The next step is to prepare payload for the primary SAM target using the SNMP loader message and get it encrypted using the KMS service. An encryption endpoint in KMS service is implemented as an “Asynchronous request processing with polling” model. In this model, MMSA first sends a request to the KMS service and receives a task ID in response.MMSA then uses this task ID to periodically check the status of the encryption by sending additional requests. This process continues until the status indicates that the encryption is complete. Once the status is marked as completed, MMSA sends a final request using the task ID to retrieve the encrypted data. In the case where different hardware groups are supported, the payloads of all targets are encrypted, and the encryption process can be triggered in parallel.

[0183] Operation 6: Once the firmware payload is generated for primary SAM, then it is packaged with the rest of the target readers. A manifest is used to tie all target payloads and it is encrypted. This encryption works the same as target encryption where the MMSA submits a request to the KMS service, receives a task ID, and uses it to check the status. Once the request is completed, another call is made to obtain the encrypted payload.

[0184] Operation 7: The last step is to pack all target payloads and manifest into a single firmware file. If a user requests firmware for multiple readers and wants them bundled into a single file, firmware files of all readers are zipped into one file.

[0185] The expectation is that the overall upgrade process should not be significantly longer when upgrading readers with the new 1-file firmware compared to using a multi -file upgrade method. The challenge is that 1-file firmware needs to be generated for each individual reader; firmware generated for one reader cannot be used for another, unlike the existing process where the same set of files is used to upgrade all readers. As highlighted in the previous section, generating reader-specific firmware involves many tasks and multiple API calls, including asynchronous ones. Therefore, the design aims to minimize latency in the generation of readerspecific firmware to reduce the impact on the overall upgrade process.

[0186] As mentioned above, a user may request firmware for many readers in a single request, with the count potentially reaching 50 or more. The service is able to handle this size of a load while providing acceptable throughput. It is able to handle firmware requests for one reader, 10 readers, and 50 readers, or more, managing varying loads effectively.

[0187] The usage or load on this service will vary over time. When a new firmware version is released, many customers will want their readers upgraded to access new features. Similarly, high load may occur when there is a security issue in the existing firmware version and a new version is released to resolve it. In such cases, customers may request upgrades, or the device provider may need to enforce them, leading to a drastic increase in service load. During periods when no new version is available, the service experiences minimal load. Therefore, scalability is crucial. The service is able to automatically scale up to meet increased demand for firmware and scale down during periods of low or no demand to optimize costs.

[0188] The firmware generation process involves multiple steps, many of which need to beexecuted sequentially. Some of these steps include network calls that may fail for various reasons. Failures can also occur in other steps. Therefore, it is crucial to implement checkpointing so that the firmware generation process can resume from the step where it failed, rather than starting from the beginning.

[0189] Because many steps are involved in firmware generation, failures can occur at any step. For example, if the KMS service is unavailable, the steps involving it will not work, but this should not affect the entire firmware generation process. Other steps that do not depend on KMS service should continue to be processed, and the service can remain functional, receiving requests from tools and performing other tasks. Once the failed component, in this example the KMS service, is restored, the service can resume working with it to complete the firmware generation. The service provides fault tolerance.

[0190] The firmware generation may need to be exposed through messaging in addition to the API. This allows tools to submit firmware generation requests by posting a request message to a topic (e.g., Amazon SQS, Kafka, or another messaging platform) and receiving the response from a queue. MMSA uses a similar setup for configuration change commands.

[0191] Proper monitoring and logging are required for this service for error detection, performance tracking, and scaling, as it involves complex processing and has interfaces with KMS service, SDI, and other internal MMSA services.

[0192] The firmware generation is implemented as asynchronous process. A new “firmware request” endpoint is added to the firmware service to receive requests. This firmware request endpoint can perform basic validation and persists the request details in a database. The firmware request endpoint also provides a request ID to the requestor so that the requestor can then use the request ID to query the status of the request via another endpoint (e.g., a request status endpoint). This request status endpoint can provide status of firmware generation. If the request is for multiple readers, the request status endpoint can provide status for all readers. When firmware generation is completed for one or more readers, the status response includes a link to download the firmware for a completed reader. Using the link, the user can download the generated firmware while firmware generation for other readers continues asynchronously. This may be implemented using a firmware download endpoint. If the user has requested a bundled zip file, then a link for the same is available in the status request endpoint upon completion of firmware generation for all the readers. User can use the link to download the zip file that contains compressed firmware files of all readers.

[0193] In case of error, details are available in the request status endpoint. A file corresponding to the reader in the zip file contains the details of the failure. Both the requeststatus endpoint and the firmware download link will only work for the user who originally requested firmware generation and from the tool used for the original request. If a different user tries to access the request status endpoint or the download link, or if the requests are made from different tools, they will not work. This ensures end-to-end security. The generated firmware may be made available for download only for a certain period (e.g., one day, one week, etc.), after which it will be removed from the firmware service.

[0194] Once the firmware files are downloaded, tools are used for updating status request service with the status of the firmware upgrade to the reader(s). Readers are locked until the service is informed of the reader firmware upgrade status. The status can indicate either successful or failed. During the lock period, both configuration change requests and firmware generation requests are rejected for the locked readers. Tools are used to update the reader firmware upgrade status to this service to remove the lock on the reader. The main reason for this restriction is to prevent tools from making both configuration and firmware changes simultaneously to the readers. Changes can be made one after the other in any order, but not at the same time. This is to ensure stable operation of the readers. Another reason is to ensure that reader history is accurately captured by forcing tools to update the status in a linear fashion. Both configuration and firmware history of readers are very important for many other validations.Implementations

[0195] As this is going to be asynchronous processing, the request will first be accepted by the facade layer and then processed in the background. This means that tool’s requests will be validated and accepted by a facade process, while firmware generation will be handled by a background process. Generating firmware involves at least two asynchronous requests to the KMS service. This requires making a request, waiting for it to complete, and then retrieving the data from KMS. If a single process performs all the firmware generation tasks, it will be blocked during the KMS requests. To prevent this, the firmware generation process can be divided among multiple processes and can be executed by different code / processors. For example, one processor can submit the request to the KMS and, without waiting for its response, process the next request in the queue. Another processor can pull the response from the KMS when it is ready and continue with the subsequent steps. This approach allows firmware generation to be non-blocking. There are other similar blocking scenarios in firmware generation. To effectively manage these, the overall firmware generation may be carried out by several processors (e.g., five processors).

[0196] The facade layer generates a unique request ID, inserts the request details into the database, and sends a message to the associated message queuing service with the request ID for the background file generation process to pick up and start processing the request. To enable processors to pick the correct requests or tasks, messages to the message queuing service are tagged with the processor name, and processors select messages tagged with their respective names.

[0197] A message queuing service (MQS) is used to transfer requests from one processor to the next. The first processor retrieves the request details from the message it picks from MQS. Once it completes the processing, it sends a message to MQS with the request or task ID, tagging it with the name of the next processor. The next processor will pick up the message tagged with its name and continue processing the request. This way, requests are processed sequentially by multiple processors. One approach is to have a single MQS queue from which all processors consume and publish messages. In this setup, the processor name will be part of the message, and each processor will consume only the messages tagged with its name. Another approach is to have one MQS queue per processor. Each processor consumes messages from its designated queue and, after processing, publish messages to the next processor queue. This approach requires the same number of MQS queues as there are processors, but it is easier to track the messages waiting for each processor, allowing for dynamic scaling based on queue length. For this discussion, this implementation uses the single MQS queue approach, but it can be easily changed in other implementations.

[0198] An example of a database platform is Amazon DynamoDB, which may be used as the database mainly for two main reasons. First, it is scalable and prioritizes availability and partition tolerance over consistency, meaning that stale reads are possible. However, this is acceptable as read operations are primarily for providing status updates to the user during request processing which need not be very accurate. For write operations, the application flow ensures that only one processor updates an item / record at a time since the processors work sequentially, preventing any race conditions. The second reason for choosing DynamoDB is its flexible data model, which allows for adding and updating different attributes at various stages of firmware generation. Other advantages of DynamoDB include low latency, high availability and durability, cost-effectiveness (with a pay-as-you-go model that is beneficial given the uncertain future database size requirements), and the fact that it is a managed service on AWS.

[0199] When the facade layer inserts request details into the database, it may use the request ID as the partition key. To initiate firmware generation, it also sends a message to MQS naming the pre-processor to indicate that it will handle the request next.

[0200] Because firmware generation is an asynchronous process involving multiple steps, sharing the progress and status of these steps via a status endpoint is beneficial. Client tools use this information to estimate the approximate completion time and inform the end user of the progress and current status. There are two status that users can be informed of first, status of overall request; and second, status of individual readers. When the overall request status is still in progress, the firmware generation for each individual reader can have the varying status. FIG. 14 illustrates the request status, according to an embodiment. FIG. 15 illustrates the reader status, according to an embodiment.

[0201] FIG. 16 illustrates the data and control flow in a firmware build system, according to an embodiment. An API (facade layer) 1600 is provided that exposes a firmware request endpoint 1650, a request status endpoint 1652, a firmware download endpoint 1654, and a firmware upload endpoint 1656. More or fewer endpoints may be implemented with the API 1600. Middleware includes a database 1660 (e.g., DynamoDB), a message exchange 1662 (e.g., Amazon SQS), and a firmware repository 1664. Backend services include a pre-processor 1670, a target encryptor 1672, a manifest encryptor 1674, a one file composer 1676, and a postprocessor 1678. The backend services 1670-1678 may be implemented using services, monolithic applications, or the like.

[0202] A user 1680 may interface with the API 1600 through a browser, client program, or the like, to request FW for a single or multiple readers (operation 1610). The firmware request endpoint 1650 interfaces with the database 1660 to create one or more records, files, or other data to track the request. A request ID is created, and request details are inserted into the database (operation 1611). In operation 1612, the pre-processor 1670 manages the request.

[0203] While the pre-processor 1670 is working, a message is sent from the message exchange 1662 to the firmware request endpoint 1650 identified with the request ID and to indicate the pre-processor status (operation 1613). The message exchange 1662 interfaces with the firmware request endpoint 1650 to provide a response (operation 1614). The response is provided to the user 1680 with a URL to check on the status of the request (operation 1615).

[0204] To check on the status, the user 1680 may interface with the request status endpoint 1652 to request the status (operation 1620). A query is sent to the database with the request ID provided in the request (operation 1621). The status for one or more readers is retrieved and provided to the user 1680 (operation 1622).

[0205] To request to download firmware, the user 1680 may interface with the firmware download endpoint 1654 to transmit a request to download firmware (operation 1630). The firmware download endpoint 1654 verifies whether the requestor has access to download thefirmware by looking up the request in the database 1660 (operation 1631). If the requester has sufficient access, then the firmware file is obtained from the firmware repository 1664 (operation 1632) and downloaded to the user 1680 (operation 1633).

[0206] To upload firmware, an engineer 1682 (or other administrative person) may interface with the firmware upload endpoint 1656. The firmware and related files or a location of the firmware and related files is sent in the request (operation 1640) and the manifest and other firmware binary files are uploaded to the firmware repository 1664 (operation 1641).

[0207] The backend services 1670-1678 perform a multitude of functions. Many of these functions are initiated using the message exchange 1662. In an embodiment, the pre-processor 1670 retrieves a message identifying the pre-processor from the message exchange 1662 and fetches request details from the database 1660 using the request ID. It them parses the data and inserts records for each reader / firmware combination in the database 1660 with the request ID as a partition key and a reader ID and firmware version as a sort key. Other validations may be performed related to the requestor, the requested FW version, and requested device. Details may be saved in MMSA datastore. After processing, the pre-processor 1670 sets the status to indicate encryption initialization for each record in the table and sends a requestor message to the message exchange 1662 for each record. This is used to initiate the next backend service, manifest encryptor 1672.

[0208] The target encryptor 1672 retrieves a message identifying the encryptor from the message exchange 1662 and extracts reader details from the database using a task ID. It then prepares an encryption payload for all of the targets of the reader. A single request with all of the target payload is submitted to the KMS services. A task ID from KMS service and status indicating that encryption is in progress are updated in the database 1660. A message identifying the manifest encryptor and the same task ID is posted to the message exchange 1662. This is used to initiate the next backend service, manifest encryptor 1674.

[0209] The manifest encryptor 1674 retrieves a message identifying it from the message exchange 1662 and uses the task ID to get a corresponding record from the database 1660. Using the KMS task ID, the manifest encryptor 1674 invokes the KMS service to get the target encrypted payload for all of the targets. Using the encrypted target payload, the manifest encryptor 1674 prepares the payload for manifest. The manifest payload is submitted to the KMS service, which returns an updated task ID. This updated task ID is stored in the database 1660 and a message identifying the one file composer is posted to the message exchange 1662. This is used to initiate the next backend service, one file composer 1676.

[0210] The one file composer 1676 retrieves a message identifying it from the messageexchange 1662 and pulls details from the database 1660 using the task ID. Using the manifest task ID (updated task ID), the one file composer 1676 invokes the KMS service to get the manifest encrypted payload. The one file composer 1676 then prepares the 1 -file FW using encrypted target payload and the encrypted manifest payload. The 1 -file FW is uploaded to the firmware repository 1664 with a structured filename under a bucket with a name of the request ID. The request ID is the unique request identifier provided by the firmware service. The one file composer 1676 then updates the status to indicate processing has completed in the database 1660 and posts a message identifying the post-processor to the message exchange 1662.

[0211] The post-processor 1678 retrieves a message identifying the post-processor from the message exchange 1662 and pulls details from the database 1660 using the task ID. The postprocessor 1678 also pulls a primary request record from the database 1660 and adds the firmware to a list of finished readers. This processor then checks the list of finished readers to determine whether the FW file is generated for all readers in the request. If not, then no further processing is performed and the post-processor 1678 will check again when the next 1 -file is composed. If FW generation for all readers is completed, then the post-processor 1678 changes the status of the primary request record to indicate it is finished and generates a zip file with all of the reader’s FW files. Once all of the reader’s FW files are zipped, the post-processor 1678 may delete any individual FW files. These files are then stored in the firmware repository 1664.

[0212] The requester can provide reader details in the request body using the same structure discussed above, in addition to the option of uploading the details in a data serialization format file to the service. The firmware service also offers users the choice to download the generated files individually or as a single compressed zip file.

[0213] To capture the reader upgrade status in the MMSA device repository, users may call the services after upgrading their readers. They must use the same request ID generated during the original firmware file generation process and provide the upgrade status of each reader in a data serialization format message.

[0214] Users may include status updates of several readers in a single message or in multiple messages. For instance, if a user has received firmware files for ten readers in the original request, they can update the status of five readers first and the remaining readers later. However, because the firmware originated from the common request, status update messages must use the same request ID and the correct firmware filename. Similar to the firmware file generation request process, users can upload a data serialization format file containing these reader details or share them through the request body. Upgrade status reporting is essential for maintaining reader’s firmware details accurate in ODM device repository.On-Prem Installation

[0215] Installing, setting up, and running a local device management system in an onpremises installation is useful in some contexts to provide a client or customer the ability to configure and manage their own devices locally, handle keys and other sensitive information, and maintain strong security zones.

[0216] FIG. 19 is a diagram illustrating a network topology for an on-premises installation 1900, according to an embodiment. A wide-area network (e.g., Internet) 1902 is used to connect a cloud service provider 1904 with customer network components. The customer network components include a customer central server 1906, a browser executing an app 1908 from the central server 1906, and a gateway 1910. The customer network components act in concert to manage one or more reader devices 1912A-F. The reader devices 1912A-F may be installed (e.g., reader devices 1912D-F) at controlled resources (e.g., entries, secure assets, etc.). The reader devices 1912A-F may be programmed or configured at the gateway 1910.

[0217] The customer central server 1906 hosts the API that the customer or integrators connect to (e.g., via browser 1908). The customer central server 1906 may include various components, such as a database, an orchestrator, a trust manager, a keystore, and the like. The database is used to store device configuration data, network configuration, keys, and the like. The database may be a relational database, such as SQL Server by Microsoft®.

[0218] The customer central server 1906 connects to the gateway 1910 via a secure connection. In an embodiment, a gRPC server is created on the customer central server 1906 using a certificate and / or a private key. A custom trust manager is used. The trust manager is only used for the customer central server 1906. The trust manager verifies the public key. The trust manager also checks that the thumbprint of the certificate is stored in the database of the customer central server 1906. If the certificate is valid but the gateway 1910 has been uninstalled, no connection is allowed to the customer central server 1906.

[0219] An orchestrator may be implemented as part of the server 1906. The orchestrator is started by the customer central server 1906 during the central server’s startup routine. The customer central server 1906 generates the following and passes it to the orchestrator: 1) a certificate for the orchestrator server; and 2) a private key for the orchestrator server. A client certificate is generated and signed by the orchestrator. A key manager is created using the customer central server 1906 client certificate and private key. A trust manager is created using the orchestrator. The key and trust manager are used to create an SSL Context.

[0220] Another connection to the customer central server 1906 is to one or more cloudresources from the cloud service provider 1904. The cloud service provider 1904 may expose one or more REST endpoints for the customer central server 1906 to use to pass information, request configuration or firmware updates, or perform other management tasks for the reader devices 1912A-F.

[0221] Reader devices may also connect to the customer central server 1906 using a secure connection. In an embodiment, the secure connection is MQTT over TCP / IP, which is an application-layer messaging protocol used to transmit reader data (such as card scans) to a backend system via a central broker. It relies on a publish-subscribe model, allowing readers to “publish” events to specific topics that a server or application can “subscribe” to for real-time processing.Customer Central Server Architecture

[0222] The following provides an overview of the high-level approach, major modules, and details of various components of the customer central server 1906.

[0223] At a high level, the architectural design of the customer central server 1906 ensures reuse to leverage team knowledge and skill sets. The architecture is designed to grow as required to a configurable, unified device manager. The customer central server 1906 acts as a hub to support desktop apps (e.g., via browsers), client / server on-prem, and connected cloud-based functions and API access.

[0224] The three major modules of the customer central server 1906 include the manager, the reader manager, and the credential configuration manager. The manager provides the framework, general aspects of the server’s database, user interface implementation, and other capabilities. The reader manager provides reader configuration (both PC and controller resident) capabilities. The credential configuration manager provides credential configuration, credential aspects of the server’s database, and key store capabilities.The Manager

[0225] The manager provides an HTTP API that is implemented using RESTFul API over HTTPS. A WebSocket Secure (WSS) API provides secure, full-duplex, bidirectional communication over a long-lived TCP connection. The WSS interface provides real time feedback / direct communication between components. Using the WSS interface, a user may configure application settings and configuration assets, such as device settings, environment settings, business logic choices / defaults, and the like. The manager provides central storage and management of all settings.

[0226] Notifications may be issued via various channels, for example, email and Short Messaging Service (SMS) notifications, configurable for chosen events and as needed.

[0227] User management is provided to manage local (on-prem) users, corresponding cloud services, and defines role(s) for each use case. The user management configuration is stored in a database, and optionally authenticated via AD / LDAP or cloud AuthN / Z. Certificate management is also provided to handle lifecycle of a certificate, including creating, retrieving, renewing certificates. A reporting tool is provided via the manager to generate PDF or HTML reports based on predefined rules.

[0228] The manager may also provide a messaging protocol broker to facilitate communication with remote service (e.g., the cloud services 1904).

[0229] The manager also supports third party communication services to provide communication with third party controllers. Communication is handled using network connection (IP) and leverages secure, standardized access control communication protocols such as Open Supervised Device Protocol (OSDP) to manage readers.

[0230] A secure, standardized access control communication protocol such as OSDP for reader devices can provide a modern, secure, two-way communication standard that replaces older protocols like Wiegand, enabling encrypted data transfer, remote management, and advanced features like reader supervision (checking for tampering / malfunctions) over just two wires, making readers more secure, versatile, and efficient for access control systems.The Reader Manager

[0231] The reader manager provides various functions related to configuring, deploying, initializing, upgrading, troubleshooting, and otherwise managing reader devices 1912A-F. The reader manager include a reader configuration module to configure readers, setup reader settings using OIDs / Values or SNMP messages for a targeted reader. The reader manager may also use a set of tools (e.g., CT schema, reader device configuration parser tool, CT visualizer tool). The reader manager may be used to upgrade the reader firmware. The reader manager handles connections between the gateway 1910 or customer central server 1906 and the readers. It supports communication to the reader device 1912A-F through different connection types, such as serial, Wi-Fi, or via a controller.The Credential Configuration Manager

[0232] The credential configuration manager provides support for various components of the on-prem installation 1900. The credential configuration manager includes printer support tomanage drivers and capabilities to print and drive cards into inline encoders. It is also used to support RFID middleware and chip personalization through use of encoding templates, data aggregation, and card production workflows. The RFID middleware may be used to manage communication between desktop USB readers and RFID chips, use of PC / SC readers and other software, and support a wide range of readers and chips.

[0233] The credential configuration manager also works with a keystore to manage the secure storage of keys, store symmetric keys and certificates (e.g., either software or via a hardware module (HSM)), and scale to include additional or alternative keystores as they are developed and deployed.Additional Modules

[0234] Other additional modules may be implemented with the manger, reader manager, and credential manager modules. These general modules may include user interface modules to support web UI, browser-based UI that is supported across several browsers. The general modules may also include logging and auditing system support to produce logs for diagnostic purposes. The logging and auditing systems may work in conjunction with existing operating system logging capabilities.

[0235] The general modules may also support packaging and installation of firmware, software, or other programmable code to provide distributable images, initial installations, updates, rollbacks, or uninstallations. Packages may be distributed in a self-contained installer. A command line interface (CLI) may be used to deploy the packages.

[0236] The general modules may also support entitlement and license management to manage license installation and enforcement mechanisms. This ensures that the server executes with properly installed and verified (e.g., licensed) software. A signed and encrypted XML document is used to control usage allowance and feature enablement.

[0237] The general modules may also provide for data services to connect to database onpremises and in the cloud. Connection management to the databases and session management is included in the scope of the abilities of these modules.Customer Central Server Services

[0238] The customer central server 1906 is configured to host a Server service / appli cation. The Server can run either as an application or a service. The Server runs a REST API, an embedded web server that is used to serve the frontend.

[0239] A server configuration application is used to change the default database connectionsettings, recover access to the default admin account, etc. This server configuration application is a different application running on the same server using the same web server ports as the Server. The server configuration application can change the ports that the Server uses and restart the services. If the user does not want to use the default database configuration, for example they want to use an existing instance of SQL Server instead of SQL LocalDB, they can use the server configuration application to point the Server to an instance of SQL Server and provide the correct credential to connect to the database. The server configuration application may connect to the Server using a secure connection (e.g., using a private / public key pair).The Gateway

[0240] The gateway 1910 can be installed on a different computer than the Server. The gateway’s function is to facilitate the secure communication between the Server and reader devices 912A-F. Typically the gateway is installed on a laptop, although this may be just for convenience to move around a facility to access reader devices 912A-F. Reader devices are connected to the gateway 1910 using a USB connection.

[0241] The gateway 1910 may support several different direct hardware connections, such as USB or OSDP or similar secure, standardized communication connections. Every connection has some trust and should not lower the default trust store behavior. The gateway 1910 may securely connect over a network to one or more reader devices 1912A-F or control boards 1914A-C using MQTT over TCP / IP.

[0242] A connection between the gateway 1910 and browser is only supported on the localhost. It uses the default trust manager factory to check server trust, check client trust, and check the certificate issuer.

[0243] The gateway 1910 may also be used to access and configure control boards 1914A-C via OSDP or a similar secure, standardized access control communication protocol, which are used to perform access control, alarm management, and other scheduled operations on the reader devices 1912A-F that it controls. Control panels may be reconfigurable by flashing existing hardware with new software’s specific firmware code, which avoids hardware replacement costs. The connection between the gateway 1910 and control boards 1914A-C may be secured using a trust manager and key manager.

[0244] The gateway 1910 may also access other APIs that are exposed on-prem or over a wide-area network (e.g., Internet). These APIs are triggered by a data URL being opened from the browser executing on the gateway 1910. The gateway 1910 may be pre-registered as a handler of the data URL. Some of the parameters provided by the data URL include thewebserver certificate for the gateway 1910 or the Server on the customer central server 1906.

[0245] The gateway 1910 may also connect to on-prem Server executing on customer central server 1906 using gRPC. An SSLContext is made using keys and / or certificates to secure the gRPC connection.

[0246] The gateway 1910 may also connect to cloud resources using HTTPS over TCP / IP. The certificate and private key are used to create an SSL context.The Orchestrator

[0247] The orchestrator takes care of creating generating messages for reader devices 1912A- F. The orchestrator runs next to the Server and communicates with the cloud server 1904. The Server executing on customer central server 1906 instructs the orchestrator to perform some action related to an arbitrary communications channel. The orchestrator does not care how a reader device 1912A-F is physically connected. Its job is to create messages for a reader device 1912A-F and interpret the response. How the message get to the reader is outside the scope of orchestrator.

[0248] The orchestrator maintains two gRPC connections to allow bidirectional communication to the gateway 1910. A certificate is passed as a startup parameter to the orchestrator from the gateway 1910. A private key for the client certificate is passed as a startup parameter to the orchestrator from the gateway 1910. A key manager is created using the private key and certificate. A trust manager is created using a certificate. The trust manager and key manager are used to create the SSL context used in the communications from the gateway 1910 to the orchestrator. A similar key exchange and trust manager creation is used to establish a secure connection in the other direction (orchestrator to gateway 1910).Reader Devices

[0249] A smartcard reader device 1912A-F may operate in offline mode (e.g., without an Internet connection). As discussed above, OIDs are used to identify different categories of information. Example OID categories include, but are not limited to, Configuration OID, Keyset OID, and KeysetRef OID. A Configuration OID stores the configuration of a specific attribute of a reader device (e.g., LED color in idle state). A Keyset OID stores a keyset (e.g., a set of keys that work together). Keysets may be stored in keystores and managed with namespaces. A KeysetRef OID is used to look up what keyset should be used for a specific context. There may be multiple keysets loaded in a reader device 1912A-F, with keysets being used for a different operations.

[0250] A default keyset (also referred to as a transport keyset) may be programmed into a reader device 1912A-F before it leaves the manufacturer. They keys in the default keyset may be limited to initial operations (e.g., enrollment, activation, initialization, etc.). Once enrolled or activated, the end user may manage the reader device 1912A-F with new keys set during enrollment.

[0251] OIDs may be locked by the manufacturer such that end users are unable to change their values. In some cases, the manufacturer may provide the ability to change OID values. These OID entries may be designated on an allowed list that is maintained by the manufacturer.

[0252] During initial deployment, the end user may desire to have the reader devices 1912A- F operate in an offline mode (e.g., not connected to the manufacturer’s central device management system). In this case, the end user may manage their devices 1912A-F using their own infrastructure (e.g., servers, host computers, data centers, etc.) that is separate from the manufacturer and inaccessible by the manufacturer and the public at large.

[0253] A reader device 1912A-F may initially be unprogrammed. In an unprogrammed state, the reader device 1912A-F has a specific profile that allows tools in an offline environment to identify the reader device 1912A-F. The unprogrammed reader device has their KeysetRef OIDs for all media keysets pointing to their Customer Namespace. The keysets OIDs are unprogrammed, hence the name “unprogrammed reader.”

[0254] Unprogrammed reader devices are the only devices that out of the box can be programmed with a Local Configuration Template (CT) containing keysets. Custom profile reader devices (03 readers) can also be programmed with a Local CT containing keysets, but they need to have their OID Allowed list extended using the administrative identity first.

[0255] Custom profile readers cannot be programmed with a local CT created by an on-prem system out of the box, but they can have their allowed OID list extended using the administrative identity, which will then allow configuration using a local CT. Access to the CT to extend the allowed OID list tightly controlled to prevent its use outside of approved use cases.

[0256] A reader device 1912A-F may be configured to operate in an “online” mode or an “offline” mode. When configured in an online mode, the reader device 1912A-F is configured by a manufacturer’s central server over a wide area network (e.g., over the Internet). In an offline mode, the reader device 1912A-F is configured locally by the customer using a customer central server 1906.

[0257] A reader device 1912A-F can report as offline capable in the customer central server 1906 when at least one of the following conditions are met: 1) the reader device 1912A-F maintains an original equipment manufacturer (OEM) allowed list that is recognized by theorchestrator running on the customer central server 1906; 2) the OEM allowed list on the reader device 1912A-F contains a recognized allowed list and has a custom profile associated with the reader device 1912A-F; or 3) the reader profile identifies as an unprogrammed reader. The reader profile is obtained by querying the profile of the reader device 1912A-F and the reader device 1912A-F returns a special code (e.g., “U0” or “U3” or some other reserved identifier).

[0258] As discussed above, configuration of a reader device 1912A-F requires the use of a CT. For local CT creation, the user needs to create a new local CT. During the creation process, the user selects values from fields or enters values into input fields. Once the user saves the CT, a JSON object is saved in the database under a DRAFT state (see lifecycle of CT above). During the creation process, the user also has the option to select media keysets. This allows the reader to read credentials that were created using specific keysets.

[0259] Media keysets are managed at the central server (e.g., customer central server 1906), where multiple keystores may be created and managed. Keystores are used to group and store keysets. A distribution center may have one keystore per customer that has all that customers keysets in it. These keystores are password protected and encrypted. A CT cannot use keysets from a keystore without providing the credentials for the keystore. Media keysets are created in the keystores. A media keyset has a type linked to a credential technology, for example HID SEOS.

[0260] To apply a local CT to a reader device 1912A-F, the user discovers the reader devices 1912A-F and selects one or more reader devices 1912A-F to configure. The user then provides the offline CT identifier and any credentials for relevant keystores. Then the user then can apply the local CT to the reader device(s) 1912A-F.

[0261] The central server (e.g., customer central server 1906 in an offline context) fetches the CT JSON from a database. Based on the CT, the central server can determine which keysets are required. The user may be prompted for and provides credentials, which are used to retrieve and decrypt the one or more keysets from the respective one or more keystores. The CT JSON is provided to the reader device configuration parser tool, which outputs the OIDs and corresponding values. The central server converts the OIDs and values to SNMP messages using the OEM SNMP keyset for the reader device 1912A-F and transmits the messages to the reader device 1912A-F one at a time through the gateway 1910.

[0262] If, during an offline configuration workflow, a reader device 1912A-F is configured with a CT that references a manufacturer’s namespace and is in offline mode, then the programming process is aborted. Alternatively, the namespace of the KeysetRef OID is changed to the customer namespace before programming. To perform this namespace change, a messagefrom the manufacturer’s central server is needed. The customer central server 1906 may obtain this message using an API to cloud services 1904.Methods of Operation

[0263] Reader discovery is implemented by a device manager via the gateway 1910. The device manager (e.g., customer central server 1906) sends a command to the gateway 1910 to enumerate the ports and the gateway responds with the communication ports. The device manager opens an available port and sends a message to obtain the current secure access module (SAM) Version. The gateway 1910 receives the message from the device manager and writes bytes to the reader device 1912A-F. The reader device 1912A-F responds and the gateway 1910 forwards that response to the device manager. The device manager then closes the port to the gateway 1910 and moves to the next enumerated port. The gateway 1910 may be constructed with several communication ports to attach multiple reader devices 1912A-F. Using the iterative approach, the device manager is able to discover all reader devices 1912A-F attached to the gateway 1910.

[0264] The gateway user may install one or more applications on the gateway 1910. Installation may be performed directly (e.g., using an install package that is downloaded or stored at the gateway 1910) or indirectly (e.g., using a link to a remote installation package). To perform a remote installation, the user can browse to a web server hosted on the customer central server 1906, and activate a hyperlink (URL) to obtain the configuration for the application installation. The gateway 1910 securely connects to a REST API (e.g., using a JSON Web Token (JWT)) on the device manager (e.g., customer central server 1906) and gets the client certificate and the server public key. The gateway 1910 then registers with the device manager using the REST API. A client universal unique identifier (UUID) for the gateway 1910 is obtained from the device manager. The UUID is used for mTLS communication to obtain configuration parameters (e.g., gRPC parameters, network addresses, and the like).

[0265] To perform template updates or deployments, a user may access the customer central server 1906 via a user interface (e.g., web browser) to obtain a list of reader devices 1912A-F managed by the customer central server 1906. The user then selects one or more of the reader devices 1912A-F to configure, a template to configure the selected reader devices 1912A-F, and initiates the action via the user interface. Identifiers of the selected reader devices 1912A-F and the identifier of the selected template are sent to the manager executing on the Server on the customer central server 1906.

[0266] The manager opens a communication session with the gateway 1910. For every OIDin the selected template, the manager transmits a package to the gateway 1910, which then writes one or more data frames to the identified reader devices 1912A-F attached to the gateway 1910. The gateway 1910 provides a response message to the manager indicating a status (e.g., successful write, error state, etc.). The manager uses the status to update the user interface for the user.

[0267] FIG. 17 is a flowchart illustrating a method 1700 for device programming, according to an embodiment. The method 1700 may be performed by an electronic system (e.g., client central server), or any of the modules, logic, circuits, processors, or components described herein.

[0268] At 1702, the method 1700 includes the operation of receiving, at a device management server, a reference to a configuration template. The device management server may be a local server, such as a client central server.

[0269] At 1704, the method 1700 includes the operation of reading, at the device management server, from a datastore, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template. In an embodiment, the device configuration template is identified using a unique identifier.

[0270] In an embodiment, the device configuration template includes version information, which is used by a management system to support versioning and migration of device configuration templates for particular hardware or software profiles, wherein the versioning is implemented using hierarchical inheritance and dependencies between parent and child device configuration templates, and wherein migration is implemented using different parents having at least one common child device configuration template migrated between them.

[0271] In an embodiment, the device configuration template supports hierarchical inheritance and dependencies between parent and child device configuration templates. In a further embodiment, the hierarchical inheritance and dependencies includes hardware attributes.

[0272] In an embodiment, the datastore that stores the device configuration template is federated using a plurality of keyspace domains to store a plurality of keys. In a further embodiment, a location of each key in the plurality of keys is identified with a keyset tuple, the keyset tuple including a keystore type, a keystore domain, a keystore instance, a keyset name, and an object identifier mapping. In another embodiment, the device configuration template includes an access control attribute, the access control attribute used to control which users are able to access the plurality of keystores.

[0273] In an embodiment, the reference to the configuration template has a corresponding orderable reference, the orderable reference including the reference to the configurationtemplate. In a further embodiment, the orderable reference includes a hardware segment, a software license segment, a reference to a configuration template, and an optional customer tag. In another embodiment, the reference to the configuration template is set to a default value in the orderable reference, the default value indicating that a backing device configuration is applicable instead of a specific device configuration.

[0274] In another embodiment, the orderable reference includes a display string attribute, the display string attribute used to display a human-friendly description of the device configuration template. In a further embodiment, the display string attribute includes a concise description subattribute, the display string attribute used to display a short version of the human-friendly description of the device configuration template. In a further embodiment, the display string attribute includes a long description sub-attribute, the display string attribute used to display a long version of the human-friendly description of the device configuration template.

[0275] In an embodiment, the device configuration is created using a schema translator, the schema translator configured to take the device configuration template as input and output a device configuration. Optionally, the schema translator is initiated on demand by a user. In a further embodiment, the device configuration template is a JavaScript Object Notation (JSON) formatted file. In a further embodiment, the device configuration template includes a metadata component, a base configuration component, and an override configuration component. In a further embodiment, the override configuration component allows for the dynamic specification of attribute values at the time of programming. In another embodiment, the device configuration template is an extensible Markup Language (XML) formatted file.

[0276] In an embodiment, the schema translator access a mapping datastore that includes mappings from attributes enumerated in the device configuration template to object identifier and value tuples. In an embodiment, the device configuration includes object identifier and value tuples.

[0277] In an embodiment, the method comprises storing in a configuration history database, information related to the programming and the device configuration used during the programming. In a further embodiment, the information related to the programming includes a timestamp of system the programming an object identifier value was performed. In a further embodiment, the information related to the programming includes a current firmware of the hardware device.

[0278] At 1706, the method 1700 includes the operation of transmitting the device configuration to a gateway for programming a hardware device, the hardware device being physically connected to the gateway, the gateway configured to program the hardware deviceusing the device configuration. The hardware device may include an offline configuration mode and an online configuration mode, where in the offline configuration mode the hardware device is only able to be configured with a local CT that references local namespace resources.

[0279] Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine- readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable storage device may include any non- transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flashmemory devices, and other storage devices and media.

[0280] A processor subsystem may be used to execute the instructions on the machine- readable medium. The processor subsystem may include one or more processors, each with one or more cores. Additionally, the processor subsystem may be disposed on one or more physical devices. The processor subsystem may include one or more specialized processors, such as a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or a fixed function processor.

[0281] Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules may be hardware, software, or firmware communicatively coupled to one or more processors in order to carry out the operations described herein. Modules may be hardware modules, and as such modules may be considered tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a machine-readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. Accordingly, the term hardware module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each ofthe modules need not be instantiated at any one moment in time. For example, where the modules comprise a general -purpose hardware processor configured using software; the general- purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. Modules may also be software or firmware modules, which operate to perform the methodologies described herein.

[0282] FIG. 18 is a block diagram illustrating a machine in the example form of a computer system 1800, within which a set or sequence of instructions may be executed to cause the machine to perform any one of the methodologies discussed herein, according to an example embodiment. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of either a server or a client machine in server-client network environments, or it may act as a peer machine in peer-to-peer (or distributed) network environments. The machine may be an onboard vehicle system, set-top box, wearable device, personal computer (PC), a tablet PC, a hybrid tablet, a personal digital assistant (PDA), a mobile telephone, cloud server, web server, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. Similarly, the term “processor-based system” shall be taken to include any set of one or more machines that are controlled by or operated by a processor (e.g., a computer) to individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.

[0283] Example computer system 1800 includes at least one processor 1802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.), a main memory 1804 and a static memory 1806, which communicate with each other via a link 1808 (e.g., bus). The computer system 1800 may further include a video display unit 1810, an alphanumeric input device 1812 (e.g., a keyboard), and a user interface (UI) navigation device 1814 (e.g., a mouse). In one embodiment, the video display unit 1810, input device 1812 and UI navigation device 1814 are incorporated into a touch screen display. The computer system 1800 may additionally include a storage device 1816 (e.g., a drive unit), a signal generation device 1818 (e.g., a speaker), a network interface device 1820 (or other communication circuitry), and one or more sensors (not shown), such as a global positioningsystem (GPS) sensor, compass, accelerometer, or other sensor.

[0284] The storage device 1816 includes a machine-readable medium 1822 on which is stored one or more sets of data structures and instructions 1824 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 1824 may also reside, completely or at least partially, within the main memory 1804, static memory 1806, and / or within the processor 1802 during execution thereof by the computer system 1800, with the main memory 1804, static memory 1806, and the processor 1802 also constituting machine-readable media.

[0285] While the machine-readable medium 1822 is illustrated in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more instructions 1824. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0286] The instructions 1824 may further be transmitted or received over a communications network 1826 using a transmission medium via the network interface device 1820 (or other communication circuitry) utilizing any one of a number of well-known transfer protocols (e.g., HTTP, TCP / IP, Ethernet, etc.). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Wi-Fi, 3G, and 4G LTE / LTE-A or WiMAX networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.Additional Notes:

[0287] The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to those shown or described. However, also contemplated are examples that include the elements shown or described. Moreover, also contemplated are examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0288] Publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) are supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.

[0289] In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to suggest a numerical order for their objects.

[0290] The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with others. Other embodiments may be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. However, the claims may not set forth every feature disclosed herein as embodiments may feature a subset of said features. Further, embodiments may include fewer features than those disclosed in a particular example.Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate embodiment. The scope of the embodiments disclosed herein is to be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

CLAIMSWhat is claimed is:

1. A device programming system, comprising: communication circuitry; memory to store instructions; and a processor subsystem, which when executing instructions stored in memory is configured to perform operations comprising: receive, at a device management server, a reference to a configuration template; read, at the device management server, from a datastore via the communication circuitry, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and transmit the device configuration to a gateway for programming a hardware device, the hardware device being physically connected to the gateway, the gateway configured to program the hardware device using the device configuration.

2. The system of claim 1, wherein the device configuration is created using a schema translator, the schema translator configured to take the device configuration template as input and output a device configuration.

3. The system of claim 2, wherein the device configuration template is a JavaScript Object Notation (JSON) formatted file.

4. The system of claim 2, wherein the device configuration template is an extensible Markup Language (XML) formatted file.

5. The system of claim 2, wherein the schema translator access a mapping datastore that includes mappings from attributes enumerated in the device configuration template to object identifier and value tuples.

6. The system of claim 1, wherein the device configuration includes object identifier and value tuples.

7. The system of claim 1, wherein the device configuration template is identified using a unique identifier.

8. The system of claim 1, wherein the hardware device is a smartcard reader device.

9. A method comprising: receiving, at a device management server, a reference to a configuration template; reading, at the device management server, from a datastore, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and transmitting the device configuration to a gateway for programming a hardware device, the hardware device being physically connected to the gateway, the gateway configured to program the hardware device using the device configuration.

10. The method of claim 9, wherein the device configuration is created using a schema translator, the schema translator configured to take the device configuration template as input and output a device configuration.

11. The method of claim 10, wherein the device configuration template is a JavaScript Object Notation (JSON) formatted file.

12. The method of claim 10, wherein the device configuration template is an extensible Markup Language (XML) formatted file.

13. The method of claim 10, wherein the schema translator access a mapping datastore that includes mappings from attributes enumerated in the device configuration template to object identifier and value tuples.

14. The method of claim 9, wherein the device configuration includes object identifier and value tuples.

15. The method of claim 9, wherein the device configuration template is identified using a unique identifier.

16. The method of claim 9, wherein the hardware device is a smartcard reader device.

17. A non-transitory machine-readable medium comprising instructions for managing device configuration, which when executed by a device management server, cause the device management server to: receive, at the device management server, a reference to a configuration template; read, at the device management server, from a datastore, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and transmit the device configuration to a gateway for programming a hardware device, the hardware device being physically connected to the gateway, the gateway configured to program the hardware device using the device configuration.

18. The machine-readable medium of claim 17, wherein the device configuration is created using a schema translator, the schema translator configured to take the device configuration template as input and output a device configuration.

19. The machine-readable medium of claim 18, wherein the device configuration template is a JavaScript Object Notation (JSON) formatted file.

20. The machine-readable medium of claim 18, wherein the device configuration template is an extensible Markup Language (XML) formatted file.

Images