Patent Application
20250119302
This application generally relates to providing user ID information stored in a secure area of a mobile device.
A person's sensitive information is increasingly stored on electronic devices. For example, a user's financial information (e.g., credit card or debit card information) can be stored in a mobile device, and a secure application (often referred to as a “wallet” application) can access the financial information in the course of providing the information to an external device (e.g., to a credit-card reader).
A person's sensitive, personally identifying information can also be stored electronically. For example, a digital copy of a user's driver's license, state or student ID card, business ID card, passport, or other identifying card, document, certificate, license, accreditation, or credential, etc., may be stored on a mobile device. Here, the digital copy is not merely a photograph of the user's card or document, but rather is a digital version of the card or document that is credentialed, encrypted, and certified by a digital signature from the issuing authority. For example, a digital driver's license is a digital version of a physical driver license or state ID (or any physical ID), and can be issued or provisioned onto a mobile device by the relevant issuing authority (e.g., the state or country). Once provisioned onto a user's device, a digital driver's license can have the same legal status as a physical driver's license. Similarly, a digital ID issued by an entity such as a university or a business can have the same rights and privileges as physical IDs issued by such entities.
Secure personal information, such as a digital ID, is provisioned to a mobile device and stored on a secure hardware portion of that mobile device. The secure hardware portion is separate from the main hardware portions (e.g., the memory of the secure hardware portion is separate from the main volatile and non-volatile memory of the mobile device), and therefore the secure hardware portion is not accessible by most applications or hardware on the mobile device. Instead, the secure hardware portion is only accessible by trusted application(s) and trusted hardware on the device that have special access permission. For example, a wallet application may be a trusted application provisioned by the provider of the mobile device and granted access to the secure hardware portion of the mobile, e.g., through a separate, trusted processor and related memory structure that is granted access to the secure hardware portion.
In particular embodiments, the secure hardware portion and the information it contains is not accessible by the main processors (e.g., main CPUs and GPUs) of the mobile device or most of the applications executing on the mobile, including, in some embodiments, even the operating system running on the mobile device. The secured, isolated hardware portion of the mobile device may be referred to as “eSE” or “Enhanced Secure Element,” among many other names (e.g., TrustZone) and the digital keys to encrypt or decrypt the data securely stored in this area cannot be tampered with, and the secured area is not susceptible to man-in-the-middle or other saturation attacks. In particular embodiments, a trusted application may require a user to authenticate themselves (e.g., by using a biometric sensor on the mobile device) in order to access the information in the secure hardware portion of the device.
Storage and provisioning of secure information, such as a mobile driver's license, can be determined according to standards established by the relevant industry. Provisioning refers to the act of uploading and storing the secure information on the mobile device. As an example, the Department of Motor Vehicles (DMV) in a particular state or an equivalent government entity has the source of truth (which may be called a system of record or “SOR”) of all the individuals who have obtained a driver's license or a state ID in that state. The DMV can issue a digital equivalent of the physical forms of identification, via a verified and trusted electronic process, and the DMV is therefore the “issuing authority” of those credentials. Computing device(s) to which digital ID credentials are issued become the ID holder(s). A provisioning process can include scanning a physical document of record, performing a real-time or liveness check of the person within a view of a device's camera, and verification of information and submission to the issuing authority for adjudication and approval. After approval, a digital version of the ID credential and a payload called Mobile Security Object (MSO) is safely stored within the trusted, secured hardware storage space that is inaccessible by non-trusted components and processes of the communication device.
While the example above relates to provisioning an ID from a government agency (e.g., for a state-issued ID or a passport), this disclosure contemplates that identification credentials can issue from other sources (e.g., schools, business, associations, etc.). Provisioning of this information may be similar to the example described above. For instance, a provisioning process for digital ID information may begin by determining whether a computing device that will store the credentials contains the trusted application/secured hardware infrastructure. If so, then the enrollment process begins, which may include capturing information verifying the user (e.g., through documents or in-person processes). Some remote enrollment processes may include a liveness detection feature, which ensures that a person is visible in an image or video feed captured by the computing device, e.g., by determining whether the image or video feed contains human like features (e.g., based on facial landmarks) and/or human-like movements (e.g., eye blinking). An enrollment process may then include one or more notification verification (e.g., having the user and/or the issuing authority, or both, verify the process), and if that step is successful, then the credentials may be provisioned.
In particular embodiments, the format of how a digital ID credential is stored in the eSE is based on the mDOC standard as represented in ISO 18013-5, and the interaction between the ID-holding computing device and a reading device (which requests user-identifying information from the computing device) is governed by the ISO 18013-5 standard.
Once credentialed ID information is provisioned to an ID-holding computing device, the user of the computing device can share their credentialed ID information with any verified reader or terminal (which may be referred to herein as an “external device”) that requests ID information from the user. For example, an external device can be an NFC or QR-code reader, e.g., a terminal at an airport checkpoint or other security checkpoint (e.g., to access a secured area of a business, of a medical facility, of a government facility, etc.). These external devices are examples of in-person transactions in which the user whose ID information is being requested is in the physical vicinity of the external device requesting the information. Another example is online transactions, in which an external device (e.g., a server device or other computing device) requests ID information from a user over a network channel, such as over the internet. For example, a user attempting to rent a car may need to verify that they have a valid driver's license, a user attempting to buy alcohol may need to verify their age, and a user attempting to withdraw money from a bank account may need to verify that they are one of the verified account holders.
A backend server registers reader devices as a condition of providing service to the reader device (which can be any external device) through a trusted application, e.g., through a wallet application on the mobile device. The backend server and the trusted application make up an ecosystem or platform that manages the trusted application and the secure information; in many instances, the same entity (e.g. Samsung) manages the backend server, the trusted application, and the creation/distribution of the mobile device and its secured hardware, providing a coherent and secure approach.
First, a validating certificate (a reader root certificate) specific to a reader device or set of reader devices is provided to the server, which stores the reader root certificate in a database of trusted reader devices. As explained herein, a reader root certificate may be shared by many different reader devices, and therefore this reader root certificate may validate any one of them. For example, a particular vendor of a terminal used for security screening at an airport may provide a reader root certificate for all of its terminals, or for a certain make/model of terminal, and as a result each corresponding terminal device would use that reader root certificate in a subsequent request for a user's identifying information. This approach is more secure than, for example, merely relying on an external device's device ID, which is much more easily spoofed. In other examples, a reader root certificate may pertain to a particular computing device (e.g., a server device), which provides that reader root certificate in a subsequent request for a user's identifying information.
The backend server communicates with a trusted application on the mobile device, and provides reader root certificates to the mobile device over a secured communication channel. For example, the server may provide reader root certificates to the mobile device each time the user provisions a new identification credential (e.g., a driver's license, a passport, etc.) to their secured hardware location. As another example, the server may refresh reader root certificates at a particular timeframe, e.g., every 30 days, and as a result, the mobile device receives certificates that were uploaded to the server's trusted reader database since the server last provided reader root certificates to the mobile deice.
Step 120 of the example method of
For online, remote transactions, the relying party (RP) would enroll into a Wallet Portal and save a trusted public key. Then, when an on-device application or web-based client (e.g., a web browser) makes a request, the initial session establishment message will contain information signed by the RP's private key corresponding to the public key stored in Wallet Portal. The device will therefore recognize that the request is coming from a trusted application.
To establish a communication session, an in-person external device may generate an ephemeral keypair. A request from an external device may include requests to establish a communication session for transmitting information regarding the user's identity or may include an explicit request for the information itself, e.g., once a communication session is established. For example, an in-person reader device may transmit a session establishment request, which includes a header signed by the reader root certificate.
Step 130 of the example method of
Step 150 of the example method of
In particular embodiments, once authorized, a request from an external device may be fulfilled automatically, i.e., the mobile device, via the trusted application, may obtain and transmit the user's score identifying information to the external device without further user input. For instance, this disclosure describes below an example in which requests can be automatically fulfilled based on contextual determinations. Other embodiments provide a UI to the user so that the user can decide whether to proceed with an authenticated request (i.e., a request in which the certificate chain supplied by the external reader device matches one stored by the mobile device) or to proceed with a request that is not authenticated (i.e., because the certificate supplied by the external reader device does not match one stored by the mobile device).
In particular embodiments, a request for a user's identifying information may include a subset of the identifying information stored in the secure hardware portion of the mobile device. For example, a user attempting to buy an alcoholic product may need to verify only their legal age; while a user attempting to transfer money from a bank account may need to verify their name, address, and date of birth; while yet another user attempting to rent a car may need to verify their name, age, and license ID number and expiration date. Therefore, rather than transmitting the user's entire credential (e.g., the entire stored ID, as if physically presenting the ID to the requestor or transmitting a picture of the front/back of the ID), particular embodiments may identify the specific information being requested and then transmit only that information to the requestor. This approach limits the data that each requestor receives, increasing the security of user information, e.g., in case of a data breach at the requesting entity. For instance, a user attempting to buy an alcoholic drink need not provide their entire ID information (e.g., license ID number, home address, etc.), and therefore this information would not be at issue if the transmitted data was subject to unauthorized access.
In particular embodiments, the mobile device may determine and send a trust score to the requesting external device before completing the exchange of information and/or the overall transaction for which the information is sought. Here, the trust score is to ensure that the mobile-device side of the transaction is authentic, i.e., that the mobile device is not stolen or hacked, or the user account holding the digital credential is valid, or that the device is rooted by fraudsters/hackers to gain access to system level functions on the device. Upon receiving the trust score, the external device can determine whether to proceed with the transaction, whether to deny the transaction, or whether to take additional authentication measures. In particular embodiments, a trusted application (e.g., a wallet application) may also act upon the trust score, e.g., by denying a transaction or by temporarily locking the user's mobile device or the trusted application, in order to prevent unauthorized transactions.
A trust score may depend on the mobile device's current context. For example, a trust score may be based on the mobile device's current location. If the current location corresponds to a known location of the user, or to a location that the user frequently appears, then that suggests the transaction is relatively more trustworthy. Another example context is whether the mobile device has been unlocked recently and/or the duration with which the identifying information has been provisioned on the mobile device. For instance, a device that has recently been unlocked several times with a user's biometric data indicates a relatively more trustworthy transaction, as does a relatively longer-term provisioning of credentials. Other examples of context include a user's involvement with their device or trusted application (e.g., whether the device is new or is a device which is 6 months old), device rooted status, attestation status, trusted-application account usage history, network connectivity status, etc.
In particular embodiments, trust scores may take on more importance in offline or other remote transactions in which there is no in-person review or oversight. For instance, during an in-person or offline transaction, a mobile device may provide a low trust score, but such transactions often have a human review element (e.g., a person can see the user presenting the mobile device) or an automated review element (e.g., a face scanner can scan the user's face and compare the in-person scan to an image of the user's face on the ID). In contrast, remote or online transactions are more difficult to verify, and therefore the trust score may take on a more important role in the transaction, in that the third-party associated with the external device may take relatively more actions based the trust score.
A mobile device may run low on battery, and at some point, the battery level may become so low that the device powers off many system components, including the device's display and the processors that execute the operating system on the mobile device. In this state, the device may appear to be completely inoperative, although it may have some residual battery power left; i.e., the powering-off process described above usually occurs before the device has absolutely no battery level left.
A device that is in the low-battery level described above may present difficulties for the user regarding the user's need to validate their identity. For example, suppose a user is at the airport and needs to validate their identity to security personnel. If the user's identity is stored on the mobile device, then the low-power level described above prevents the user from validating their identity, which may lead to serious problems (e.g., missing their flight and experiencing any related personal or professional consequences as a result). However, in order to avoid this problem and make the device operable for the at-times critical purpose of providing in-person validation of the user's identity, the device may periodically power on a short-range communication module of the mobile device while the device is in the low-battery level. For example, a short-range communication module may include an NFC module, a Bluetooth module, or the like.
The short-range communication module may be powered on, e.g., every few seconds or every few milliseconds. A requesting reader device continuously transmits an interrogation to look for responding devices around it. If the mobile device's short-range communication module detects an interrogation signal, it then transmits a response to the reader device. Moreover, the mobile device may then power on a trusted processor of the mobile device that can access the secure hardware location of the mobile device on which the user's identifying information is securely stored. In particular embodiments, the trusted processor and associated hardware (e.g., buffers and memory caches) may be physically separate from the mobile device's main processors that, e.g., execute the mobile device's operating system and related applications, and therefore the trusted processor may be powered on without having to power the full processing capabilities of the mobile device, which a low battery level may not support.
In addition, the mobile device may power on a biometric sensor that corresponds to a biometric authentication signal that authenticates the user and authorizes access to the secure information identifying the user. For example, once a communication session is established between the mobile device and the requesting device, then the requesting device may transmit its request for identifying information, and in response the mobile device may power on its trusted processor and its biometric sensor(s) related to authentication. In particular embodiments, the device may also power on an identification to the user that the sensor is active, e.g., an LED light associated with a fingerprint reader on the mobile device may flash to alert the user to the fact that the sensor is now receiving power. In particular embodiments, the communication module, trusted processor, and biometric sensor(s) may be powered on without powering on any display of the mobile device, and therefore the user may not be aware of the state of the external device's request absent some identification (e.g., an LED light) that the biometric sensor is active and ready to receive input from the user.
If the user authenticates their biometric(s) through the biometric sensor(s), then the trusted processor may obtain the requested information from the secure location on the mobile device and transmit the information, via the short-range communication module, to the requesting reader device. The mobile device may then power down the trusted processor and biometric sensors, and may return the short-range communication module to a duty-cycled state, in which power is only periodically supplied. Thus, using the techniques described herein, a user may authenticate their identity via their mobile device to a requesting device that is in the user's vicinity of, even when the mobile device is in such as low-power state that its normal operations cannot be performed.
In particular embodiments, in certain circumstances a request from an external device can be automatically approved by the mobile device, so that the user does not have to provide further input (e.g., via UI 205 in the example of
In particular embodiments, the current context of a mobile device may be used along with a previous context of the mobile device during the time the user granted a previous request to determine whether to automatically grant a current request. For example, a location of the mobile device during a previously granted access request may be compared to the device's current location, and if two locations match and the requesting device provides the same certificate that accompanied the previously granted request, then request may be automatically granted. Other examples of current context include whether the mobile device has recently been unlocked, a time of day (e.g., when accessing a particular secured area for a business), a user's involvement with their device or trusted application (e.g., whether the device is new or is a device which is 6 months old), device rooted status, attestation status, trusted-application account usage history, network connectivity status, and so forth.
In step 310, the user or the mobile device determines whether the external device will receive all the identifying information (e.g., based on the information requested and on the permissions previously granted or currently granted by the user of the mobile device). For instance, the user may decide whether to approve the request in full, i.e., whether to grant access to all the information requested. If yes, then in the example of
This disclosure contemplates any suitable number of computer systems 400. This disclosure contemplates computer system 400 taking any suitable physical form. As example and not by way of limitation, computer system 400 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these. Where appropriate, computer system 400 may include one or more computer systems 400; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 400 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 400 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 400 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.
In particular embodiments, computer system 400 includes a processor 402, memory 404, storage 406, an input/output (I/O) interface 408, a communication interface 410, and a bus 412. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.
In particular embodiments, processor 402 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 402 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 404, or storage 406; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 404, or storage 406. In particular embodiments, processor 402 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 402 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 402 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 404 or storage 406, and the instruction caches may speed up retrieval of those instructions by processor 402. Data in the data caches may be copies of data in memory 404 or storage 406 for instructions executing at processor 402 to operate on; the results of previous instructions executed at processor 402 for access by subsequent instructions executing at processor 402 or for writing to memory 404 or storage 406; or other suitable data. The data caches may speed up read or write operations by processor 402. The TLBs may speed up virtual-address translation for processor 402. In particular embodiments, processor 402 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 402 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 402 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 402. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.
In particular embodiments, memory 404 includes main memory for storing instructions for processor 402 to execute or data for processor 402 to operate on. As an example and not by way of limitation, computer system 400 may load instructions from storage 406 or another source (such as, for example, another computer system 400) to memory 404. Processor 402 may then load the instructions from memory 404 to an internal register or internal cache. To execute the instructions, processor 402 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 402 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 402 may then write one or more of those results to memory 404. In particular embodiments, processor 402 executes only instructions in one or more internal registers or internal caches or in memory 404 (as opposed to storage 406 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 404 (as opposed to storage 406 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 402 to memory 404. Bus 412 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 402 and memory 404 and facilitate accesses to memory 404 requested by processor 402. In particular embodiments, memory 404 includes random access memory (RAM). This RAM may be volatile memory, where appropriate Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 404 may include one or more memories 404, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.
In particular embodiments, storage 406 includes mass storage for data or instructions. As an example and not by way of limitation, storage 406 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 406 may include removable or non-removable (or fixed) media, where appropriate. Storage 406 may be internal or external to computer system 400, where appropriate. In particular embodiments, storage 406 is non-volatile, solid-state memory. In particular embodiments, storage 406 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 406 taking any suitable physical form. Storage 406 may include one or more storage control units facilitating communication between processor 402 and storage 406, where appropriate. Where appropriate, storage 406 may include one or more storages 406. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.
In particular embodiments, I/O interface 408 includes hardware, software, or both, providing one or more interfaces for communication between computer system 400 and one or more I/O devices. Computer system 400 may include one or more of these I/O devices, where appropriate. One or more of these I/O devices may enable communication between a person and computer system 400. As an example and not by way of limitation, an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An I/O device may include one or more sensors. This disclosure contemplates any suitable I/O devices and any suitable I/O interfaces 408 for them. Where appropriate, I/O interface 408 may include one or more device or software drivers enabling processor 402 to drive one or more of these I/O devices. I/O interface 408 may include one or more I/O interfaces 408, where appropriate. Although this disclosure describes and illustrates a particular I/O interface, this disclosure contemplates any suitable I/O interface.
In particular embodiments, communication interface 410 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 400 and one or more other computer systems 400 or one or more networks. As an example and not by way of limitation, communication interface 410 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 410 for it. As an example and not by way of limitation, computer system 400 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 400 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 400 may include any suitable communication interface 410 for any of these networks, where appropriate. Communication interface 410 may include one or more communication interfaces 410, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.
In particular embodiments, bus 412 includes hardware, software, or both coupling components of computer system 400 to each other. As an example and not by way of limitation, bus 412 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 412 may include one or more buses 412, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.
Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.
Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.
The scope of this disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend.
This application claims the benefit under 35 U.S.C. § 119 of U.S. Provisional Patent Application No. 63/542,431 filed Oct. 4, 2023, which is incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 63542431 | Oct 2023 | US |
