Systems and methods for device 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 processing circuitry, which when executing instructions stored in memory is configured to perform operations comprising: receive a reference to a configuration template; read 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 program, via the communication circuitry, a hardware device using the device configuration.

Description

SYSTEMS AND METHODS FOR DEVICE PROGRAMMINGPRIORITY APPLICATION(S)

[0001] This application claims priority to Indian Provisional Patent Application Serial Number 202411073901, filed on September 30, 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 radiofrequency 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, modern 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 illustratedby way of example, 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 managing configuration files, according to an embodiment; and

[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.DETAILED DESCRIPTION

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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 system 102 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 internet-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.

[0027] 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.

[0028] 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, semistructured 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.

[0029] 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.

[0030] 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 or changes in default attribute values. A CT has a lifecycle of Draft, Publishable, Published, and Deactivated. Once Published a CT is locked it cannot be changedexcept by an administrative override. This is to preserve the history when a CT is applied to a UUID.

[0031] 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.

[0032] Data serialization format objects within a CT support inheritance. Each link in the inheritance chain logically copies attribute / value pairs from its immediate parent, 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.

[0033] 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”.

[0034] 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.

[0035] A UUID 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).

[0036] 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.

[0037] 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.

[0038] 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 UUID, 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.

[0039] At the time of manufacture by a device manufacturer 106, the device is given a UUID. 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

[0040] 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.”

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] As an example, a Structured Composite may have a regular expression of the hardware segment of “*-LLL” with “-L01” indicating a particular software license segmentof 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.

[0047] 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.

[0048] 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

[0049] 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.

[0050] 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

[0051] Manufacturers 106 and distribution centers 108 maintain separate environments so that manufacturing and distribution operations are able to continue even during networkoutages 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 a device 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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 anotification 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 reader device 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.

[0056] 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 software-version 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.

[0057] 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.

[0058] 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 todifferentiate 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-version 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>.

[0059] 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.

[0060] 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.

[0061] 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).

[0062] 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.

[0063] 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 statusto the EBS 1202 (operation 4).

[0064] 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 service 1102 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.

[0065] 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

[0066] 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”: {},}

[0067] 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 otheractivities around the use and maintenance of a device.

[0068] 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 is described 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 keystore to use and the unique processing required to securely resolve the key reference.

[0069] 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

[0070] 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.

[0071] “ 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.

[0072] “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.

[0073] “ 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 thatcontent can be unique to each supported release.

[0074] “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 provide for 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.

[0075] “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.

[0076] “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.

[0077] “ 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.

[0078] “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.

[0079] “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.

[0080] “ 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.

[0081] “ 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 theCT 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).

[0082] “ 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 specific access rules. Specific delegated authority rules can also be specified for a CT that override this basic authorization mechanism.

[0083] “ 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.

[0084] “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.

[0085] “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.

[0086] “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

[0087] 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 inheritancechain 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).

[0088] CTs support an inheritance structure that enables a base definition, the Initialization CT, which documents the state of a device as it is 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.

[0089] 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.

[0090] 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).

[0091] 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 CTsimplifies customizations as any “child” CT that inherits from the Initialization CT need only specify revisions from the Initialization CT.

[0092] 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.

[0093] 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.

[0094] 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).

[0095] 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.

[0096] 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 notprovided, the complete CT returned will not contain any hardware specific configurations.

[0097] 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 Rl.1.1.31, for example, the inheritance chain under schema vl.2 is used for complete configuration. For software version R1.1.2.3, the inheritance chain under schema version v2.0 is used. FIG. 5 is a table of microservice application programming interface (API) parameters, according to an embodiment. The parameters may be used in RESTful API.

[0098] 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).

[0099] 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).

[0100] 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.

[0101] 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.

[0102] 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 are migrated 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).

[0103] 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 hardware-version 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.

[0104] 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 softwareversions and corresponding schema versions.

[0105] When a complete CT is requested with the hardware-version 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 Rl.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 on the given software-version Rl .1.1.31.

[0106] In addition to hardware-version, 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.

[0107] 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.

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

[0109] 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.

[0110] 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-common-parent” : To associate a hardware version to a hardware Initialization CT; and“family” : To associate hardware family to the hardware version.

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

[0112] 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 Toolchains 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 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.

[0113] Device Specific Tool chains, 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.

[0114] 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 isremoved 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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).

[0119] 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

[0120] 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.

[0121] 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 the dynamically 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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 Tool chain associated with the CT type ensures correctness of the inserted values.

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

[0127] “ 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.

[0128] “ 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.

[0129] “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.

[0130] “ 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.

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

[0132] “ 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

[0133] Each CT applied to a device (including the Initialization CT that matches how itwas 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.

[0134] 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.

[0135] 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

[0136] 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 tool chains) may be used to manage CTs. The configuration schema may be applied to devices other than readers, such as credentials, controllers, encoders, etc.

[0137] 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 key stores.

[0138] 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 UUID / engine ID.

[0139] 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 computational expensive and cannot be completed insynchronous call, the parsing process is implemented as asynchronous call.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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).Key store Types and Key store Abstraction

[0144] 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 aresource or object that can be managed via SNMP. These objects can include information like device status, network statistics, or configuration settings.

[0145] 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.

[0146] 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 keyspace 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

[0147] 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.

[0148] 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.

[0149] The central server keystores support secure and managed keystores 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 keystoremay be restricted to referencing the set in which it belongs.OID Mapping

[0150] 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

[0151] 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 keystore 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.

[0152] Relative reference to Domains may be supported via the central server. Onpremises systems 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 a on-premises system Server via a server gateway.

[0153] A key store 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 key store refers to one and only one Key store. If that Key store does not exist, then the reference fails, and the CT cannot be resolved. Additionally, if the Keystore does not containthe specified Keyset, then the reference fails, and the CT cannot be resolved.

[0154] 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 Keystore 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 keystore 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.

[0155] 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 Keystore 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.

[0156] Finally, when a tuple references a relative domain and a relative keystore, the specific client is checked. If that client contains a Keystore 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 store type is present, then it is used. If the central server contains more than one instance of that Keystore 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

[0157] 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 securedatabase / repositories resident in service provider, or customer environments, including cloud based software-based HSMs offered by cloud service providers.

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

[0159] 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 Key space 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.

[0160] 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 keystore reference is used to determine which Keystore to reference for a reference in the CT. This resolution occurs when the CT is parsed.

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

[0162] 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.

[0163] 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.”

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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.

[0168] 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 key store contents.Firmware Installation File Construction

[0169] 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 reader-specific firmware file, its service interfaces with other services, the potential load it needs to support, 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.

[0170] 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.

[0171] 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.

[0172] 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.

[0173] 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.

[0174] 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 be downloaded 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.

[0175] 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 requiredFW 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.

[0176] 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.

[0177] 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.

[0178] 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.

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

[0180] 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.

[0181] 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 therequest is completed, another call is made to obtain the encrypted payload.

[0182] Operation 7: The final 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.

[0183] 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 reader-specific firmware to reduce the impact on the overall upgrade process.

[0184] 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.

[0185] 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.

[0186] The firmware generation process involves multiple steps, many of which need to be executed 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.

[0187] 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 dependon 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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 request status 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.

[0192] 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

[0193] 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).

[0194] 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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 isstill 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.

[0199] 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 preprocessor 1670, a target encryptor 1672, a manifest encryptor 1674, a one file composer 1676, and a post-processor 1678. The backend services 1670-1678 may be implemented using services, monolithic applications, or the like.

[0200] 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.

[0201] 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).

[0202] 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).

[0203] 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 the firmware 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).

[0204] 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).

[0205] 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 preprocessor 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 preprocessor 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.

[0206] 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.

[0207] 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.

[0208] The one file composer 1676 retrieves a message identifying it from the message exchange 1662 and pulls details from the database 1660 using the task ID. Using the manifesttask 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.

[0209] 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 post-processor 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.

[0210] 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.

[0211] 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.

[0212] 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 statusreporting is essential for maintaining reader’s firmware details accurate in ODM device repository.Methods o f Operation

[0213] FIG. 17 is a flowchart illustrating a method 1700 for managing configuration files, according to an embodiment. The method 1700 may be performed by an electronic system (e.g., device management system 102) or any of the modules, logic, circuits, processors, or components described herein.

[0214] At 1702, the method 1700 includes the operation of receiving a reference to a configuration template.

[0215] At 1704, the method 1700 includes the operation of reading 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.

[0216] 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. In a further embodiment, the device configuration template is a JavaScript Object Notation (JSON) formatted file. In another embodiment, the device configuration template is an extensible Markup Language (XML) formatted file.

[0217] 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.

[0218] At 1706, the method 1700 includes the operation of programming a hardware device using the device configuration. In an embodiment, the hardware device is a smartcard reader device.

[0219] 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, flash-memory devices, and other storage devices and media.

[0220] A processor subsystem may be used to execute the instruction 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.

[0221] 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 of the 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.

[0222] 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 anexample 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.

[0223] 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, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.

[0224] 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.

[0225] While the machine-readable medium 1822 is illustrated in an example embodimentto 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; magnetooptical disks; and CD-ROM and DVD-ROM disks.

[0226] The instructions 1824 may further be transmitted or received over a communications network 1826 using a transmission medium via the network interface device 1820 utilizing any one of a number of well-known transfer protocols (e.g., HTTP). 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 & Examples:

[0227] Example l is a device programming system, comprising: communication circuitry; memory to store instructions; and processing circuitry, which when executing instructions stored in memory is configured to perform operations comprising: receive a reference to a configuration template; read 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 program, via the communication circuitry, a hardware device using the device configuration.

[0228] In Example 2, the subject matter of Example 1 includes, wherein the deviceconfiguration is created using a schema translator, the schema translator configured to take the device configuration template as input and output a device configuration.

[0229] In Example 3, the subject matter of Example 2 includes, wherein the device configuration template is a JavaScript Object Notation (JSON) formatted file.

[0230] In Example 4, the subject matter of Examples 2-3 includes, wherein the device configuration template is an extensible Markup Language (XML) formatted file.

[0231] In Example 5, the subject matter of Examples 2-4 includes, 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.

[0232] In Example 6, the subject matter of Examples 1-5 includes, wherein the device configuration includes object identifier and value tuples.

[0233] In Example 7, the subject matter of Examples 1-6 includes, wherein the device configuration template is identified using a unique identifier.

[0234] In Example 8, the subject matter of Examples 1-7 includes, wherein the hardware device is a smartcard reader device.

[0235] Example 9 is a method comprising: receiving a reference to a configuration template; reading from a datastore, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and programming a hardware device using the device configuration.

[0236] In Example 10, the subject matter of Example 9 includes, 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.

[0237] In Example 11, the subject matter of Example 10 includes, wherein the device configuration template is a JavaScript Object Notation (JSON) formatted file.

[0238] In Example 12, the subject matter of Examples 10-11 includes, wherein the device configuration template is an extensible Markup Language (XML) formatted file.

[0239] In Example 13, the subject matter of Examples 10-12 includes, 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.

[0240] In Example 14, the subject matter of Examples 9-13 includes, wherein the device configuration includes object identifier and value tuples.

[0241] In Example 15, the subject matter of Examples 9-14 includes, wherein the device configuration template is identified using a unique identifier.

[0242] In Example 16, the subject matter of Examples 9-15 includes, wherein thehardware device is a smartcard reader device.

[0243] Example 17 is a non-transitory machine-readable medium comprising instructions for managing device configuration, which when executed by a machine in an online system cause the machine to: receive a reference to a configuration template; read from a datastore, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and program a hardware device using the device configuration.

[0244] In Example 18, the subject matter of Example 17 includes, 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.

[0245] In Example 19, the subject matter of Example 18 includes, wherein the device configuration template is a JavaScript Object Notation (JSON) formatted file.

[0246] In Example 20, the subject matter of Examples 18-19 includes, wherein the device configuration template is an extensible Markup Language (XML) formatted file.

[0247] In Example 21, the subject matter of Examples 18-20 includes, 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.

[0248] In Example 22, the subject matter of Examples 17-21 includes, wherein the device configuration includes object identifier and value tuples.

[0249] In Example 23, the subject matter of Examples 17-22 includes, wherein the device configuration template is identified using a unique identifier.

[0250] In Example 24, the subject matter of Examples 17-23 includes, wherein the hardware device is a smartcard reader device.

[0251] Example 25 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement of any of Examples 1-24.

[0252] Example 26 is an apparatus comprising means to implement of any of Examples 1- 24.

[0253] Example 27 is a system to implement of any of Examples 1-24.

[0254] Example 28 is a method to implement of any of Examples 1-24.

[0255] 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.

[0256] 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.

[0257] 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.

[0258] 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 processing circuitry, which when executing instructions stored in memory is configured to perform operations comprising: receive a reference to a configuration template; read 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 program, via the communication circuitry, a 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 a reference to a configuration template; reading from a datastore, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and programming a 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 machine in an online system cause the machine to: receive a reference to a configuration template; read from a datastore, a device configuration corresponding to the reference to the configuration template, the device configuration based on a device configuration template; and program a 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