Patent ID: 12204887

DETAILED DESCRIPTION

The present disclosure is described with reference to the attached figures. The figures are not drawn to scale, and they are provided merely to illustrate the disclosure. Several aspects of the disclosure are described below with reference to example applications for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide an understanding of the disclosure. The present disclosure is not limited by the illustrated ordering of acts or events, as some acts may occur in different orders and/or concurrently with other acts or events. Furthermore, not all illustrated acts or events are required to implement a methodology in accordance with the present disclosure.

System hardware components of an IHS, such as CPUs, DIMMs, PICe Cards (e.g., Graphics, Network, WiFi, etc.), SSD/HDD devices and the like may need replacement and/or updating for assorted reasons, such as to enable an upgrade to a faster processor, faster memory, and/or faster graphics. Other reasons for replacing components may be to support the latest internal bus technologies, such as ATA/133or Serial ATA, to enable to use external peripherals using USB or FireWire technology, to increase expansion slot potential, and the like. Additionally, a motherboard upgrade may also be performed for distinct reasons, including to meet latest technology requirements.

A motherboard is the backbone of an IHS; that is, one that provides a platform for connecting many components (e.g., CPU, GPU, memory, etc.) and peripheral devices (e.g., NIC cards) used by the IHS. It is of critical importance both in terms of system performance and connectivity. Nevertheless, motherboard replacement can be a burdensome affair, particularly due to custom settings that need to be transferred from the previous motherboard to the replacement motherboard. For example, firmware (e.g., BIOS, UEFI, etc.) on an Information Handling System (IHS) can be customized from its default settings. If a particular default setting is not what a user desires, the user may be required to perform multiple steps on multiple machines to reconfigure the firmware. For example, the customer may be required to search for or create a configuration update file for use with the firmware manipulation or flashing utility. Then the specific procedures for that motherboard and/or firmware should be followed to install the configuration update file, such as a firmware update to flash the BIOS. This process, however, can present difficulties in cost and time to deploy, as well as pose a risk that the process does not complete properly and renders the firmware unusable. These risks may be compounded when a customer desires to update or configure new default firmware settings on multiple devices.

For IHS vendors, Reliable, Accessible and Serviceable (RAS) is a key pillar of product quality and providing seamless, secure, and reduced downtime possesses significant value to IHS customers and addresses their current pain points reported for part replacement scenarios. For example, DELL TECHNOLOGIES, which is a vendor of high quality IHSs that span across a broad range of product offerings, has reported approximately 3.2 million motherboard replacements in the field during fiscal year 2022, and each motherboard replacement has yielded a pain point due to the necessity of manually migrating the custom BIOS and/or UEFI settings from the previous motherboard to the replacement motherboard.

The motherboard may fail for several reasons, thus needing replacement. For example, electrical spikes and surges caused by problems with electrical wiring, problems with the power service outside the house, or the result of a lightning strike may damage the motherboard to the point that it needs replacement. Additionally, dust, pet hair and debris may block air circulation that keeps the machine cool, thus causing the motherboard to overheat. Overheating of the motherboard can also occur due to gaming, rendering video, watching videos, fluctuations in power supply, laptop heatsink blocked with dust, and the like. The motherboard may also incur manufacturer design defects. Motherboards are mass produced and there are chances that manufacturing defects may occur. Another motherboard failure may include a Power On Self Test (POST) failure in which the IHS does not boot to DXE phase due to SPI flash corruption, a condition whose only option may be to dispatch a new motherboard for replacement.

After the motherboard is dispatched using conventional techniques, there exists no intelligence available to retrain the EC/BIOS firmware on the replacement motherboard to the context of the previous motherboard. Example settings that may affect the context of the motherboard may include any flash update revision checks, BKC attributes, OS/VM context configurations, and the like. If the mother board replacement is not handled properly, the certificates/keys inside the UEFI secure boot database may be lost such that the security context cannot be restored back to the same level as on with faulty mother board. Additionally, if BIOS Security configurations (e.g., Secure Boot/TPM On/Thunderbolt Security, Custom Boot Order variables, etc.) are not restored, then platform custom security settings may be restored to factory defaults such that the user sees a change in security behavior. Firmware actions to previously reported telemetry events, such as firmware tampering, Root of Trust (ROT), and the like may be lost, and thus firmware remediation actions will become difficult while unexpected behavior may be observed on the IHS. Upon loosing vendor support (e.g., SupportAssist or Excalibur profiles), BIOSConnect URLs, HTTPs TLS certificates, the platform may lose the capability of recovery remediation functionality, thus needing to be reconfigured again. Considering a virtual environment, the host Operating System (OS) and Virtual Machine (VM) settings saved into UEFI NVRAM would be set to factory default, which forces the user to reconfigure the settings.

As will be described in detail herein below, embodiments of the present disclosure provide a solution to the aforementioned problems, among others, using a seamless and secure motherboard replacement system and method that transfers context information associated with a motherboard that is being replaced to a replacement motherboard in a secure manner. The seamless and secure motherboard replacement system and method creates a context-based binary object (blob) in an NVMe storage space, which is stored with various platform security attributes, boot path configuration, networking profiles, and the like in an incremental fashion based on update versioning. The system and method also provide a first power on authentication protocol to securely identify the binary object by dynamically determining the previous part versus current replaced part security context and enable the first boot. The system and method also provide a Functional Context Restore(FCR) with BIOS/EC meta-data path to dynamically train the platform boot path with a previous/last successful boot path context.

For purposes of this disclosure, an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an IHS may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., Personal Digital Assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. An IHS may include Random Access Memory (RAM), one or more processing resources such as a Central Processing Unit (CPU) or hardware or software control logic, Read-Only Memory (ROM), and/or other types of nonvolatile memory.

Additional components of an IHS may include one or more disk drives, one or more network ports for communicating with external devices as well as various I/O devices, such as a keyboard, a mouse, touchscreen, and/or a video display. An IHS may also include one or more buses operable to transmit communications between the various hardware components. An example of an IHS is described in more detail below.

FIG.1shows an example of an IHS configured to implement the motherboard replacement system and method described herein. It should be appreciated that although certain embodiments described herein may be discussed in the context of a desktop or server computer, other embodiments may be utilized with virtually any type of IHS. Particularly, the IHS includes a baseboard or motherboard100, which is a printed circuit board (PCB) to which components or devices are mounted to by way of a bus or other electrical communication path. For example, Central Processing Unit (CPU)102operates in conjunction with a chipset104. CPU102is a processor that performs arithmetic and logic necessary for the operation of the IHS.

Chipset104includes northbridge106and southbridge108. Northbridge106provides an interface between CPU102and the remainder of the IHS. Northbridge106also provides an interface to a random access memory (RAM) used as main memory114in the IHS and, possibly, to on-board graphics adapter112. Northbridge106may also be configured to provide networking operations through Ethernet adapter110. Ethernet adapter110is capable of connecting the IHS to another IHS (e.g., a remotely located IHS) via a network. Connections which may be made by Ethernet adapter110may include local area network (LAN) or wide area network (WAN) connections. Northbridge106is also coupled to southbridge108.

Southbridge108is responsible for controlling many of the input/output (I/O) operations of the IHS. In particular, southbridge108may provide one or more universal serial bus (USB) ports116, sound adapter124, Ethernet controller134, and one or more general purpose input/output (GPIO) pins118. Southbridge108may also provide a bus for interfacing peripheral card devices such as PCIe slot130. In some embodiments, the bus may include a peripheral component interconnect (PCI) bus. Southbridge108may also provide baseboard management controller (BMC)132for use in managing the various components of the IHS. Power management circuitry126and clock generation circuitry128may also be utilized during operation of southbridge108.

Additionally, southbridge108is configured to provide one or more interfaces for connecting mass storage devices to the IHS. For instance, in an embodiment, southbridge108may include a serial advanced technology attachment (SATA) adapter for providing one or more serial ATA ports120and/or an ATA100adapter for providing one or more ATA100ports122. Serial ATA ports120and ATA100ports122may be, in turn, connected to one or more mass storage devices storing an operating system (OS) and application programs.

An OS may comprise a set of programs that controls operations of the IHS and allocation of resources. An application program is software that runs on top of the OS and uses computer resources made available through the OS to perform application-specific tasks desired by the user.

Mass storage devices connected to southbridge108and PCIe slot130, and their associated computer-readable media provide non-volatile storage for the IHS. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by a person of ordinary skill in the art that computer-readable media can be any available media on any memory storage device that can be accessed by the IHS. Examples of memory storage devices include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices.

A low pin count (LPC) interface may also be provided by southbridge108for connecting Super I/O device138. Super I/O device138is responsible for providing a number of I/O ports, including a keyboard port, a mouse port, a serial interface, a parallel port, and other types of input/output ports.

The LPC interface may connect a computer storage media such as a ROM or a flash memory such as a non-volatile random access memory (NVRAM) for storing BIOS/firmware136that includes BIOS program code containing the basic routines that help to start up the IHS and to transfer information between elements within the IHS. BIOS/firmware136comprises firmware compatible with the Extensible Firmware Interface (EFI) Specification and Framework.

The LPC interface may also be utilized to connect virtual NVRAM137(e.g., SSD/NVMe) to the IHS. The virtual NVRAM137may be utilized by BIOS/firmware136to store configuration data for the IHS. In other embodiments, configuration data for the IHS may be stored on the same virtual NVRAM137as BIOS/firmware136. The HIS100may also include a SPI native NVRAM140coupled to the BIOS136.

BMC132may include non-volatile memory having program instructions stored thereon that enable remote management of the IHS. For example, BMC132may enable a user to discover, configure, and manage the IHS, setup configuration options, resolve and administer hardware or software problems, etc. Additionally or alternatively, BMC132may include one or more firmware volumes, each volume having one or more firmware files used by the BIOS' firmware interface to initialize and test components of the IHS.

As a non-limiting example of BMC132, the integrated DELL Remote Access Controller (iDRAC) from DELL, INC. is embedded within DELL POWEREDGE servers and provides functionality that helps information technology (IT) administrators deploy, update, monitor, and maintain servers with no need for any additional software to be installed. The iDRAC works regardless of OS or hypervisor presence from a pre-OS or bare-metal state because iDRAC is embedded within the IHS from the factory.

It should be appreciated that, in other embodiments, the IHS may comprise other types of computing devices, including hand-held computers, embedded computer systems, personal digital assistants, and other types of computing devices. It is also contemplated that the IHS may not include all of the components shown inFIG.1, may include other components that are not explicitly shown inFIG.1, or may utilize a different architecture.

Referring now toFIG.2, examples of aspects of an EFI environment200created by BIOS/firmware136of the IHS are described. As shown, BIOS/firmware136comprises firmware compatible with the EFI Specification from INTEL CORPORATION or from the UEFI FORUM. The EFI Specification describes an interface between OS202and BIOS/firmware136. Particularly, the EFI Specification defines the interface that BIOS/firmware136implements and the interface that OS202may use in booting to use hardware210.

According to an implementation of EFI, both EFI206and legacy BIOS support module208may be present in BIOS/firmware136. This allows the IHS to support both firmware interfaces. In order to provide this, interface212may be used by legacy OSs and applications. Additional details regarding the architecture and operation of the EFI206are provided below with respect toFIG.3.

FIG.3provides additional details regarding an EFI Specification-compliant system300utilized to provide an operating environment to facilitate initialization and reconfiguration of replacement motherboards. As shown, system300includes platform hardware316and OS202. Platform specific firmware308may retrieve an OS image from EFI system partition318using an EFI O/S loader302. EFI system partition318may be an architecturally shareable system partition. As such, EFI system partition318defines a partition and file system that are designed to allow safe sharing of mass storage between multiple vendors. O/S partition320may also be utilized.

Once started, EFI O/S loader302continues to boot the complete OS202. In doing so, EFI O/S loader302may use EFI boot services304and interface to other supported specifications to survey, comprehend, and initialize the various platform components and the operating system software that manages them. Thus, drivers314from other specifications may also be present on system300. For example, the Advanced Configuration and Power Management Interface (ACPI) and the System Management BIOS (SMBIOS) specifications may be supported.

EFI boot services304provide interfaces for devices and system functionality that can be used during boot time. EFI runtime services306may also be available to the EFI O/S loader302during the boot phase. For example, a minimal set of runtime services may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system202during its normal operation. EFI allows extension of platform firmware by loading EFI driver and EFI application images which, when loaded, have access to EFI-defined runtime and boot services.

Various program modules provide the boot and runtime services. These program modules may be loaded by the EFI boot loader312at system boot time. EFI boot loader312is a component in the platform specific firmware308that determines which program modules should be explicitly loaded and when. Once the platform specific firmware308is initialized, it passes control to EFI boot loader312. EFI boot loader312is then responsible for determining which of the program modules to load and in what order.

In that context, UEFI Secure Boot is an industry-standard mechanism in the system BIOS for authenticating pre-boot code modules (e.g., device drivers or other software or firmware code). The UEFI specification defines data structures and logic for the authentication process. The BIOS maintains a Secure Boot policy having X.509 certificates, public keys, and image digests. The BIOS enforces the Secure Boot policy for each pre-boot code module that loads during the boot process. If a pre-boot code module cannot be authenticated or does not otherwise satisfy the Secure Boot policy, the BIOS does not load that module.

FIG.4illustrates an example motherboard replacement system400that may be used for secure and seamless access by various boot architectures according to one embodiment of the present disclosure. The system400executes a boot process402, such as an UEFI boot process, that takes place in multiple phases, such as a Security (SEC) phase performed by a SEC module404, a Pre-EFI Initialization (PEI) phase performed by a PEI module406, a driver execution environment (DXE) phase performed by a DXE module408, and a Systems Management Mode (SMM) phase performed by a SMM module410on an IHS, such as IHS100ofFIG.1. The boot process402may also execute an Operating System (OS) phase executed by an OS412, which is loaded and started on the IHS100. The SEC module404, PEI module406, DXE module408, and SMM module410may collectively form a BIOS/Firmware136as shown inFIG.1. In this context, the BIOS/Firmware136should be construed as encompassing at least the boot block as that term is defined above. In some embodiments, the BIOS/Firmware136may also include other components of the BIOS and even all of the BIOS. However, in some implementations, some components that may be considered as being part of the BIOS may be stored in other locations.

The system400also includes a bios root block420, a PEI interface module422, a DXE interface module424, and a NVMe storage unit430. While the PEI interface module422and DXE interface module424are shown independently of the PEI module406and DXE module408, respectively, it should be appreciated that the PEI interface module422and DXE interface module424may be integrated within the PEI module406and DXE module408without departing from the spirit and scope of the present disclosure. The PEI interface module422and DXE interface module424communicate with the NVMe storage unit430to perform the various features described herein.

In general, the NVMe storage unit430is not typically replaced when a previous motherboard440is replaced with a replacement motherboard442. As such, the system400acquires context data444from the previous motherboard440while it is still configured in the IHS, and stores the context data444as a binary object432(blob) in the NVMe storage unit430. When the replacement motherboard442is deployed in the IHS, the system400configures the replacement motherboard442with the context data446from the binary object432, when possible, so that the replacement motherboard442has the same or close to the same context as the previous motherboard440.

In one embodiment, the system400creates binary object432in the NVMe storage unit430with various platform security attributes, boot path configuration, networking profiles, and the like, in an incremental fashion based on update versioning. Restoring the context data to the replacement motherboard442is shared between the PEI and DXE phase of the boot process following motherboard replacement. The PEI interface module422initializes the factory programmed defaults based on new hardware detection and allocates the memory to store the context data446by creating a hand-off block handler.

Examples of context data that may be stored in the binary object432may include certificates and/or keys, BIOS Security configuration (e.g., SB/TPM ON/Thunderbolt security, custom boot order variables, etc.), BIOS FW revisions, a telemetry event created and notified to OS on a change, SA/Excalibur profiling BIOSConnect URLs HTTPs TLS certificates, update eDiags/Telemetry/Excalibur, EC managed NVRAM storage, certain recorded security incidents like firmware tampering, Root of Trust (ROT), host OS VM settings, and the like.

The context data restore process loads in early DXE phase and locates the NVMe namespace, based on secure authorization. Thereafter, the Context Specific Payload (CSP) is loaded and the tuning process begins with the factory programmed default versus the previous context to upgrade to the new hardware context. The restore map is published into Hand-off offset and rebooted to perform a Context Specific Payload restore based boot, which loads the OS seamlessly to the user.

The system400provides a Functional Context Restore (FCR) using a BIOS/EC meta-data path to dynamically train the platform boot path with a previous/last successful boot path context. This may be accomplished using a First Power ON authentication process (e.g., application) inside BIOS (PBA) that scans the SSD device partition to identify whether the BIOS/EC information is in sync with Host OS context or not. The meta data provides the BIOS/EC firmware previous functional context of the previous motherboard440. If the bios/EC information is not in sync, the firmware may be re-trained according to a prior motherboard dispatch state.

FIG.5illustrates an example context data updating method500that may be performed to update context data in the binary object432when an event is encountered according to one embodiment of the present disclosure. For example, the method500may be performed to the previous motherboard440to gather context data associated with the previous motherboard440so that when a replacement of the previous motherboard440occurs, the context data may be transferred to the new replacement motherboard442. Additionally or alternatively, the context data updating method500may be performed in whole or in part by the motherboard replacement system300described above with reference toFIG.3. The method500may be performed at any suitable time, such as during the PEI and/or DXE phase of a boot process.

While the present embodiment describes a process for updating the binary object432during a system re-boot process, at runtime (OS phase of execution) and in a context healthy state, an EC/BIOS coordinated method may be performed to push context data as it is identified using a secure connection through the BIOS and UEFI storage driver to the NVMe storage unit430.

At step502, the method500starts. At step504, the method500determines whether any events have occurred that may result in a change to the context of the previous motherboard440. Examples of such events may include addition and/or removal of a hardware component (e.g., NIC card, I/O expansion card, video card, etc.), BIOS configuration change, change of security context, and the like. At step506, if any context changing events are not encountered, the method500continues at step508to continue booting in the normal manner in which the process ends at step510. If, however, context changing event are encountered, processing continues at step512.

At step512, the method500captures (e.g., acquires) the context data with firmware revision information. Thereafter at step514, the method500updates the binary object432with the new context data, and if no binary object currently exists, the method500may generate a new binary object432to store the newly captured context data. The method500then writes the newly updated binary object432to the EFI system partition (ESP) at step516. In one embodiment, the binary object432may be encrypted with a certificate and/or key to ensure its integrity and security. Thereafter, the method500continues processing at step508to finish the boot process.

The method500described above may be performed any time the IHS is re-booted or initially booted for the first time following manufacture. Nevertheless, at step510, the method500ends.

FIG.6illustrates an example motherboard replacement method600that may be performed to transfer context data446to the replacement motherboard442when it is deployed in the IHS. Additionally or alternatively, the motherboard replacement method600may be performed in whole or in part by the motherboard replacement system400described above with reference toFIG.4. The method600may be performed any time a motherboard is replaced in the IHS. In one embodiment, the method600may be performed when the replacement motherboard442is initially installed in the IHS to replace the previous motherboard440.

At step602, the method600starts. At step604, the method600enters the PEI phase of a boot process. The method600then determines whether the replacement motherboard442configured in the IHS is being powered on for the first time at step606. If not, processing continues at step608in which the boot process is continued on to completion, and the method600ends at step610. If the IHS is being powered on for the first time, however, processing continues at step612.

At step612, the PEI interface module422generates and sends a Hand Over Block (HOB) to be used by the DXE interface module424in which the hob indicates whether the replacement motherboard442should be updated with the context data stored in the NVMe storage unit430. At step614, the DXE phase commences. Thereafter, the DXE interface module424commences its operation, and at step616, it determines whether the context data in the replacement motherboard442should be updated according to the received hob. If not, the method600ends at step610. If the context data is to be updated, however, processing continues at step618. The DXE interface module424at step618searches for the storage unit. For example, scenarios exist in which the NVMe storage unit430has not been installed in the IHS and therefore, no updating of the context data on the replacement motherboard442is possible. If, at step620, the NVMe storage unit430is not found, the method600ends at step610, but if found, processing continues at step622in which the DXE interface module424identifies the binary object432in the NVMe storage unit430. Once found, the DXE interface module424at step624verifies the integrity of the binary object432, for example, using the encryption key that was used to encrypt the binary object432as described above with reference to step514ofFIG.5. At step626, if the binary object432is good, processing continues at step628; otherwise, processing continues at step610in which the method600ends.

At step628, the DXE interface module424parses the binary object and accesses the context data stored inside. Thereafter at step630, the DXE interface module424determines whether the existing hardware configuration of replacement motherboard442can accept the context data. If so, processing continues at step632in which the replacement motherboard442is tuned based on the new hardware configuration; otherwise, processing continues at step634in which the previous configuration is maintained. For example, if the CPU on the replacement motherboard442has only four cores, while the context data includes certain configuration settings indicating that the CPU on the previous motherboard440had eight cores, the DXE interface module424may not update the replacement motherboard442with those configuration settings due to the core count mismatch. As another example, a security context of the previous motherboard440may have utilized a certain virtualization function that is not available on the replacement motherboard442. As such, the DXE interface module424may not implement the security context, and/or update a logfile indicating that the security context of the previous motherboard440cannot be implemented properly in the replacement motherboard442. At this point, the method600ends at step610.

AlthoughFIGS.5and6describe example methods500and/or600that may be performed to update the context data in the binary object432, and update a replacement motherboard442with that context data, the features of either method500and/or600may be embodied in other specific forms without deviating from the spirit and scope of the present disclosure. For example, either of the methods500and/or600may perform additional, fewer, or different operations than those described in the present examples. For another example, either of the methods500and/or600may be performed in a sequence of steps different from that described above. As yet another example, certain steps of either method500and/or600may be performed by other components in the IHS100other than those described above.

It should be understood that various operations described herein may be implemented in software executed by processing circuitry, hardware, or a combination thereof. The order in which each operation of a given method is performed may be changed, and various operations may be added, reordered, combined, omitted, modified, etc. It is intended that the invention(s) described herein embrace all such modifications and changes and, accordingly, the above description should be regarded in an illustrative rather than a restrictive sense.

The terms “tangible” and “non-transitory,” when used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals; but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including, for example, RAM. Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may afterwards be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link.

Although the invention(s) is/are described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention(s), as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention(s). Any benefits, advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.

Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The terms “coupled” or “operably coupled” are defined as connected, although not necessarily directly, and not necessarily mechanically. The terms “a” and “an” are defined as one or more unless stated otherwise. The terms “comprise” (and any form of comprise, such as “comprises” and “comprising”), “have” (and any form of have, such as “has” and “having”), “include” (and any form of include, such as “includes” and “including”) and “contain” (and any form of contain, such as “contains” and “containing”) are open-ended linking verbs. As a result, a system, device, or apparatus that “comprises,” “has,” “includes” or “contains” one or more elements possesses those one or more elements but is not limited to possessing only those one or more elements. Similarly, a method or process that “comprises,” “has,” “includes” or “contains” one or more operations possesses those one or more operations but is not limited to possessing only those one or more operations.