Patent Description:
There may be a desire to store and share information about elevator trips taken at locations of interest such as the Empire State Building. When people exchange this information, there may be a desire to confirm that this information is authentic. This is because, for example, with the advent of artificial intelligence in area of image processing, photo memories can be faked.

<CIT> discloses an elevator accident public system based on a block chain. A plurality of nodes are used for storing collected elevator working state historical data are/or elevator user complaint data; the nodes are used for running an intelligent contract, when the nodes obtain the elevator user complaint data, whether an elevator event indicated by the elevator user complaint data meets an elevator accident condition or not is judged according to an elevator accident condition which is obtained in advance and used for indicating the elevator accident and the elevator working state historical data matched with the elevator user complaint data; and when the elevator event indicated by the elevator user complaint data meets the elevator accident condition, a node voting judgment is triggered, and whether the elevator event meeting the elevator accident condition is published on the nodes of the system or not is judged. According to the system, an elevator accident is published by the nodes, so that generation of information isolated island is avoided by sharing information.

Disclosed is a system for storing and sharing elevator trips, in accordance with claim <NUM>.

In some embodiments, the controller is a central authority located on the network.

In some embodiments, the ride detail information indicative of one or more of: current time; current date; current weather; the first location; and a duration of the ride.

In some embodiments, the controller is configured to: receive ride quality information indicative of one or more of: ride quality including speed, acceleration, and vibrations; ride comfort level; impressions associated with visiting the first location; and store the ride quality information with the ride detail information.

In some embodiments, the controller is configured to: obtain media data related to the visiting the first location, the media data including one or more of: picture data, video data, and audio data; and store the media data with the ride detail information.

In some embodiments, the controller is configured to receive the media data from one or more of: a mobile phone; sensors located on the elevator car, and data stored on the network.

In some embodiments, the controller is configured to: determine that portions of the ride detail information include private data; store on the database on the network the ride detail information, excluding the portions that include private data; and store on another database on the network the ride detail information that is excluded from the ride detail information stored on the database.

In some embodiments, the controller is configured to: share the nonfungible token (NFT) via one or more social media platforms on a public network.

In some embodiments, the controller is configured to: authenticate the NFT and provide data associated with the NFT to an NFT wallet on a mobile phone.

Further disclosed is a method of storing and sharing elevator trips in accordance with claim <NUM>.

In some embodiments, the method further comprises receiving ride quality information, indicative of one or more of: ride quality including speed, acceleration, and vibrations; ride comfort level; impressions associated with visiting the first location; and storing the ride quality information with the ride detail information.

In some embodiments, the method further comprises obtain media data related to the visiting the first location, a media data including one or more of: picture data, video data, and audio data; and storing the media data with the ride detail information.

In some embodiments, the method further comprises receiving the media data from one or more of: a mobile phone; sensors located on the elevator car, and data stored on the network.

In some embodiments, the method further comprises determining that portions of the ride detail information include private data; wherein storing ride detail information on the database includes: storing on the database on the network the ride detail information, excluding the portions that include private data; and storing on another database on the network the ride detail information that is excluded from the ride detail information stored on the database.

In some embodiments, the method further comprises sharing the NFT via one or more social media platforms on a public network.

In some embodiments, the method further comprises authenticating the NFT and providing data associated with the NFT to an NFT wallet on a mobile phone.

<FIG> is a perspective view of an elevator system <NUM> including an elevator car <NUM>, a counterweight <NUM>, a tension member <NUM>, a guide rail (or rail system) <NUM>, a machine (or machine system) <NUM>, a position reference system <NUM>, and an electronic elevator controller (controller) <NUM>. The counterweight <NUM> is configured to balance a load of the elevator car <NUM> and is configured to facilitate movement of the elevator car <NUM> concurrently and in an opposite direction with respect to the counterweight <NUM> within an elevator shaft (or hoistway) <NUM> and along the guide rail <NUM>.

The car controller <NUM> is located, as shown, in a controller room <NUM> of the elevator shaft <NUM> and is configured to control the operation of the elevator system <NUM>, and particularly the elevator car <NUM>. For example, the car controller <NUM> may provide drive signals to the machine <NUM> to control the acceleration, deceleration, leveling, stopping, etc. of the elevator car <NUM>. The car controller <NUM> may also be configured to receive position signals from the position reference system <NUM> or any other desired position reference device. When moving up or down within the elevator shaft <NUM> along guide rail <NUM>, the elevator car <NUM> may stop at one or more landings <NUM> as controlled by the car controller <NUM>. Although shown in a controller room <NUM>, those of skill in the art will appreciate that the car controller <NUM> can be located and/or configured in other locations or positions within the elevator system <NUM>.

Embodiments may also be employed in ropeless elevator systems using self-propelled elevator cars (e.g., elevator cars equipped with friction wheels, pinch wheels or traction wheels).

As disclosed in greater detail below, the embodiments herein provide a verifiable platform to store and share data representing elevator trips that a passenger takes at locations of interest, such as famous landmarks including the Empire State Building. The embodiments provide an industry generated blockchain application that can help passengers capture and store the data, including one or more of images, videos, audio and text, representing occurrences of their visits to locations of interest and ensure that a later reviewing of the data is genuine and verifiable.

Turning to <FIG>, a system for storing and sharing elevator trips (for simplicity, a system) <NUM> is disclosed according to an embodiment. The system <NUM> includes a network <NUM>, which refers to interconnected network nodes <NUM>, linked together to exchange data and share resources with each other. A network node <NUM> may be data communication equipment (DCE) such as a modem, hub or, switch, or data terminal equipment (DTE) such as two or more computers and printers and network attached storage. One or more databases including a database (e.g., a first database) <NUM> may also be provided on the network <NUM>. The network <NUM> may include a central authority <NUM>, which may be considered a network controller (or for simplicity, a controller <NUM>) and which may authorize, support, and establish executive support for the network <NUM> and programs <NUM> running on the network <NUM>. The network <NUM> may be configured to communicate with, or be part of, a public network <NUM> such as the internet, and such communications may occur over a communications link <NUM>. The communications link <NUM> refers to the transmission media connecting two nodes. Links may be physical, e.g., cable wires or optical fibers, or free space used by wireless networks. In some embodiments the network <NUM> may be configured to send a data link <NUM> to data <NUM> stored on the network <NUM>, such as in the database <NUM>, to social media platforms <NUM> located on the public network <NUM>.

The elevator system <NUM> may be located within a location of interest (or first location) <NUM>. The elevator car <NUM> may be operationally connected to a car controller <NUM>, and the car controller <NUM> may be operationally connected to the central authority <NUM> on the network <NUM>. First and second passengers <NUM>, <NUM> may be onboard the elevator <NUM>. The passengers <NUM>, <NUM> may have first and second mobile phones <NUM>, <NUM>. The mobile phones <NUM>, <NUM> may communicate with the network <NUM> via a wireless communications network <NUM>. The mobile phones <NUM>, <NUM> may be registered with the network <NUM> with a user account for each passenger maintained on the network <NUM>. The mobile phones <NUM>, <NUM> may contain a software application <NUM>, such as a mobile version of an NFT wallet, obtained via a mobile phone app store such as the App Store maintained by Apple Inc. It is to be appreciated that the passengers <NUM>, <NUM> may have desktop versions of the NFT wallets. Sensors <NUM> onboard the elevator car <NUM> may be utilized to capture and transmit to the network <NUM>, e.g., via the car controller <NUM> or the wireless network <NUM>, various forms of media, including audio and video of the location of interest <NUM>, which may be stored as the data <NUM> on the database <NUM>. Additional sensors <NUM> may be located outside elevator car <NUM> to capture audio or video of the exterior of the location of interest <NUM>, including weather, and such additional sensors <NUM> may communicate with the network <NUM> via the wireless communications network, though wired connections are within the scope of the embodiments.

Turning to <FIG>, to provide access to the data <NUM> on the database <NUM>, the network <NUM> may be configured to manage a blockchain <NUM>, which may also be referred to as a managed blockchain. The blockchain <NUM> may be a permissioned blockchain controlled under the network <NUM>. The central authority <NUM> may determine which of the nodes <NUM> in the network <NUM> can be a node on the blockchain <NUM>. That is, the blockchain <NUM> may consist of numerous blocks of data that are stored on designated nodes of the network <NUM> that, as a result, function as small servers. The central authority <NUM> may manually provision hardware, install software, create, and manage certificates for access control, and configure networking components to handle the blockchain <NUM>. The nodes <NUM> of the network <NUM> that are assigned to the blockchain <NUM> are in electronic communication with each other and continuously exchange the newest information on the blockchain <NUM> with each other to ensure all designated nodes are updated.

In order to share data <NUM> in the database <NUM> representing elevator trips, the network <NUM> may be configured to create (e.g., mint) and lock (e.g., freeze) nonfungible tokens (NFTs) such as first and second NFTs <NUM>, <NUM> for the respective passengers <NUM>, <NUM>, e.g., to turn a digital item of interest into an asset on the blockchain <NUM>. The NFTs <NUM>, <NUM> may be similarly configured so that further reference will be to the first NFT <NUM>, which shall be generally referred to as an NFT <NUM>. The NFT <NUM> may be linked to the data <NUM>, e.g., that may include media data <NUM> (e.g. video, audio, images and/or text) indicative of the experience of passenger <NUM> during an elevator trip at the location of interest <NUM>.

The media data <NUM> that is part of the data <NUM> may be captured utilizing the sensors <NUM>, <NUM> (<FIG>) that may obtain audio and video within the elevator car <NUM> to capture the elevator experience and, in some embodiments, outside the building at the location of interest <NUM> in which the elevator car <NUM> is situated. In some embodiments, the media data <NUM> may be fetched directly from the mobile phone <NUM>, e.g., utilizing its motion, audio, image and video sensors. Such fetching may be automatic or by requesting input from the passenger <NUM> via a suitable mobile app. The images may be stored as portable network graphics (PNG) or graphics interchange format (GIF) files. Text may be available in portable document format (PDF), while music may be stored as an MP3 file format and video may be stored as an MP4. Other audio, video and image formats are within the scope of the embodiments.

The NFT <NUM> on the blockchain <NUM> may be owned by the business that owns, manages or services the elevator car <NUM>, the passenger <NUM>, or another party. As indicated, the mobile app <NUM> on the mobile phone <NUM> may be an NFT wallet that has access to the NFT <NUM> held on the blockchain <NUM>. Such access may be provided by the mobile phone <NUM> receiving from the central authority <NUM> a private key <NUM> (e.g., utilizing public key infrastructure, or PKI) linked to the NFT <NUM>. Utilizing NFT wallets, the NFT <NUM> may be shared with the other passenger <NUM> via their own NFT wallet, e.g., on their mobile device <NUM> or located elsewhere. In addition, the NFT <NUM> may be transferred to the NFT wallet of the passenger <NUM>.

An application protocol interface (API) <NUM> may be issued to the mobile phones <NUM>, <NUM> (or desktops or other devices) of the passengers <NUM>, <NUM>, directly with permission from the central authority <NUM> or via the app store. With the API <NUM>, the mobile phones <NUM>, <NUM> may be able to verify authenticity of the NFT <NUM> and fetch data <NUM>, e.g., including media data <NUM>, associated with the NFT <NUM>. That is, the API <NUM> functions as a blockchain explorer, such as Etherscan. io, which is a publicly available search engine that lets users look up, confirm and validate transactions executed on the Ethereum blockchain via, e.g., OpenSea. io (an American online NFT marketplace headquartered in New York City, USA). With authorization from the central authority <NUM>, the passengers <NUM>, <NUM> may be able to share access to the NFTs <NUM>, <NUM> with each other and with social media platforms <NUM> such as Facebook (owned by Meta Platforms). When the NFT <NUM> is shared among the passengers <NUM>, <NUM>, the API <NUM>, e.g., on their mobile phones <NUM>, <NUM> can be used to verify the authenticity of the data <NUM> associated with the NFT <NUM> and fetch the data <NUM>.

The embodiments may include operating in different modes depending on the type of passenger <NUM>, such as a visitor, an executive and a maintenance employee. When a visitor rides the elevator car <NUM>, information that may be captured as data <NUM> for the NFT <NUM> may include ride detail information such as ride date and time, geographic location of the location of interest <NUM>, elevator details, current weather, and a duration of the ride. When an executive or VIP rides the elevator car <NUM>, the ride detail information may include ride quality details, such as ride quality, a comfort level during ride, weather conditions, and/or other data associated with the building or elevator ride, and/or passenger impressions of the visit to the location of interest <NUM> that may be solicited via a mobile app <NUM>, or a user interface on a digital panel installed in the elevator car <NUM>, etc. Ride quality details may also be measured with the help of sensors in the elevator system, or as indicated may be measured by sensors on mobile phone itself. Such sensors may provide velocity, acceleration and vibration data, among other data, indicative of ride quality. For a maintenance employee, data <NUM> may include indicators of the elevator car <NUM> operating within design parameter thresholds, such as sound, vibration data, etc. This information may be simultaneously updated for all maintenance employees registered to the blockchain <NUM> via shared access to the NFTs. In each instance, media data <NUM> such as pictures, video, audio, etc., may be captured and stored as part of the ride detail information.

The data <NUM> representing ride details and ride quality details may be stored in a database <NUM> that is linked to the NFT <NUM> in the blockchain <NUM>. Private data, if collected, may be stored on another database (e.g., a second database) <NUM> on the network <NUM>, and optionally not associated with the NFT <NUM>, to comply with requirements to protect such information.

Turning to <FIG>, a flowchart shows a method of storing and sharing elevator trips according to embodiments. As shown in block <NUM>, the method includes the system <NUM>, via the central authority <NUM> (or controller <NUM>) in electronic communication with the elevator car <NUM> disposed at the first location <NUM>, storing on a database <NUM>, ride detail information, indicative of an elevator ride experience of the passenger <NUM> onboard the elevator car <NUM>. As shown in block <NUM>, the method includes the system <NUM> generating an NFT <NUM> that is linked to the ride detail information. As shown in block <NUM>, the method includes the system <NUM> uploading the NFT <NUM> to the blockchain <NUM> implemented on the network <NUM>. As shown in block <NUM>, the method includes the system <NUM> providing the NFT to an NFT wallet of the passenger <NUM>, which may be on the mobile phone <NUM> of the passenger <NUM>. As shown in block <NUM>, the method includes the system <NUM> storing, as part of the ride detail information, one or more of current time, current date, current weather, the location of interest <NUM>, and a duration of the ride.

As shown in block <NUM>, the method includes the system <NUM> receiving ride quality information, including one or more of: ride quality; ride comfort level; impressions associated with visiting the location of interest <NUM>. Other user interfaces are within the scope of the embodiments. As further shown in block <NUM>, the method includes the system <NUM> storing the ride quality information as part of the ride detail information.

As shown in block <NUM>, the method includes the system <NUM> obtaining media data <NUM> related to visiting the location of interest <NUM> including one or more of picture data, video data, and audio data. As further shown in block <NUM>, the method includes the system <NUM> storing the media data <NUM> as part of the ride detail information. As shown in block <NUM> the method includes the system <NUM> obtaining the media data <NUM> from one or more of the mobile phone <NUM> and the sensors <NUM>, <NUM> located on the elevator car <NUM> or outside the car <NUM> at the location of interest <NUM>, and stored data, e.g., previously stored on the database which may sufficiently show desired features of the location of interest <NUM> to capture the ride experience of the passenger <NUM>.

As shown in block <NUM>, the method includes the system <NUM> determining that portions of the ride detail information include private data. This could occur by the passenger utilizing the mobile app <NUM>, or an interactive elevator car panel located within the elevator car, or otherwise, to identify private data that is part of the ride detail information. As shown in block <NUM>, storing ride detail information on the database <NUM> (block <NUM>) includes the system <NUM> storing on the database <NUM> on the network <NUM> the ride detail information, excluding the portions that include private data. As also shown in block <NUM>, the method includes the system <NUM> storing on another database <NUM> on the network <NUM> the ride detail information that is excluded from the ride detail information stored on the database <NUM>.

As shown in block <NUM>, the method includes the system <NUM> sharing the NFT <NUM> via one or more social media platforms <NUM> on the public network <NUM>, e.g., utilizing a link to the NFT <NUM>. This could be performed automatically based on stored passenger preferences or based on instructions from the passenger <NUM>, e.g., utilizing the mobile app <NUM>. As shown in block <NUM>, the method includes the system <NUM> authenticating the NFT <NUM> and providing the data <NUM> associated with the NFT <NUM> to an NFT wallet, which may be, e.g., on the mobile phone <NUM>. This could be performed responsive to the passenger <NUM> seeking to authenticate the NFT <NUM> and retrieve data <NUM> stored on the network <NUM> utilizing the NFT wallet <NUM>. It is within the scope of the embodiments for the other passenger <NUM> to use its NFT wallet to authenticate the NFT <NUM> or retrieve the data <NUM>.

Turning to <FIG>, another flowchart shows more generally the method of storing and sharing elevator trips according to embodiments. As shown in block <NUM>, the method includes the system <NUM>, via the central authority <NUM> (or controller <NUM>) in electronic communication with the elevator car <NUM> disposed at the first location <NUM>, As shown in storing on a database <NUM>, ride detail information indicative of an elevator ride experience of the passenger onboard the elevator car. As shown in block <NUM>, the method includes the system <NUM> generating an NFT <NUM> that is linked to the ride detail information. As shown in block <NUM>, the method includes the system <NUM> uploading the NFT <NUM> to the blockchain <NUM> implemented on the network <NUM>.

The above embodiments provide an industry specific blockchain in a system that stores data representing occurrences of visits to locations of interest. The blockchain is configured to operate in a public mode. An elevator passenger can use an NFT generated by the system to validate their travel to locations of interest such as famous landmarks and monuments. The NFT can be linked to social media platforms where the passenger can post their authentic visit to tourist spots. APIs <NUM> may be utilized to verify authenticity of the NFT, such as by the passenger who is the subject of the NFT or by someone with whom the passenger has shared access to the NFT. APIs <NUM> may also be utilized to fetch data, including media data, associated with the NFT.

Sensor data identified herein may be obtained and processed separately, or simultaneously and stitched together, or a combination thereof, and may be processed in a raw or complied form. The sensor data may be processed on the sensor (e.g. via edge computing), by controllers identified or implicated herein, on a cloud service, or by a combination of one or more of these computing systems. The senor may communicate the data via wired or wireless transmission lines, applying one or more protocols as indicated below.

Wireless connections may apply protocols that include local area network (LAN, or WLAN for wireless LAN) protocols. LAN protocols include WiFi technology, based on the Section <NUM> standards from the Institute of Electrical and Electronics Engineers (IEEE). Other applicable protocols include Low Power WAN (LPWAN), which is a wireless wide area network (WAN) designed to allow long-range communications at a low bit rates, to enable end devices to operate for extended periods of time (years) using battery power. Long Range WAN (LoRaWAN) is one type of LPWAN maintained by the LoRa Alliance, and is a media access control (MAC) layer protocol for transferring management and application messages between a network server and application server, respectively. LAN and WAN protocols may be generally considered TCP/IP protocols (transmission control protocol/Internet protocol), used to govern the connection of computer systems to the Internet. Wireless connections may also apply protocols that include private area network (PAN) protocols. PAN protocols include, for example, Bluetooth Low Energy (BTLE), which is a wireless technology standard designed and marketed by the Bluetooth Special Interest Group (SIG) for exchanging data over short distances using short-wavelength radio waves. PAN protocols also include Zigbee, a technology based on Section <NUM>. <NUM> protocols from the IEEE, representing a suite of high-level communication protocols used to create passengeral area networks with small, low-power digital radios for low-power low-bandwidth needs. Such protocols also include Z-Wave, which is a wireless communications protocol supported by the Z-Wave Alliance that uses a mesh network, applying low-energy radio waves to communicate between devices such as appliances, allowing for wireless control of the same.

Wireless connections may also include radio-frequency identification (RFID) technology, used for communicating with an integrated chip (IC), e.g., on an RFID smartcard. In addition, Sub-<NUM> RF equipment operates in the ISM (industrial, scientific and medical) spectrum bands below Sub <NUM> - typically in the <NUM> - <NUM>, <NUM> and the <NUM> frequency range. This spectrum band below <NUM> is particularly useful for RF IOT (internet of things) applications. The Internet of things (IoT) describes the network of physical objects-"things"-that are embedded with sensors, software, and other technologies for the purpose of connecting and exchanging data with other devices and systems over the Internet. Other LPWAN-IOT technologies include narrowband internet of things (NB-IOT) and Category M1 internet of things (Cat M1-IOT). Wireless communications for the disclosed systems may include cellular, e.g. <NUM>/<NUM>/<NUM> (etc.). Other wireless platforms based on RFID technologies include Near-Field-Communication (NFC), which is a set of communication protocols for low-speed communications, e.g., to exchange date between electronic devices over a short distance. NFC standards are defined by the ISO/IEC (defined below), the NFC Forum and the GSMA (Global System for Mobile Communications) group. The above is not intended on limiting the scope of applicable wireless technologies.

Wired connections may include connections (cables/interfaces) under RS (recommended standard)-<NUM>, also known as the TIA/EIA-<NUM>, which is a technical standard supported by the Telecommunications Industry Association (TIA) and which originated by the Electronic Industries Alliance (EIA) that specifies electrical characteristics of a digital signaling circuit. Wired connections may also include (cables/interfaces) under the RS-<NUM> standard for serial communication transmission of data, which formally defines signals connecting between a DTE (data terminal equipment) such as a computer terminal, and a DCE (data circuit-terminating equipment or data communication equipment), such as a modem. Wired connections may also include connections (cables/interfaces) under the Modbus serial communications protocol, managed by the Modbus Organization. Modbus is a master/slave protocol designed for use with its programmable logic controllers (PLCs) and which is a commonly available means of connecting industrial electronic devices. Wireless connections may also include connectors (cables/interfaces) under the PROFibus (Process Field Bus) standard managed by PROFIBUS & PROFINET International (PI). PROFibus which is a standard for fieldbus communication in automation technology, openly published as part of IEC (International Electrotechnical Commission) <NUM>. Wired communications may also be over a Controller Area Network (CAN) bus. A CAN is a vehicle bus standard that allow microcontrollers and devices to communicate with each other in applications without a host computer. CAN is a message-based protocol released by the International Organization for Standards (ISO). The above is not intended on limiting the scope of applicable wired technologies.

When data is transmitted over a network between end processors as identified herein, the data may be transmitted in raw form or may be processed in whole or part at any one of the end processors or an intermediate processor, e.g., at a cloud service (e.g. where at least a portion of the transmission path is wireless) or other processor. The data may be parsed at any one of the processors, partially or completely processed or complied, and may then be stitched together or maintained as separate packets of information. Each processor or controller identified herein may be, but is not limited to, a single-processor or multi-processor system of any of a wide array of possible architectures, including field programmable gate array (FPGA), central processing unit (CPU), application specific integrated circuits (ASIC), digital signal processor (DSP) or graphics processing unit (GPU) hardware arranged homogenously or heterogeneously. The memory identified herein may be but is not limited to a random access memory (RAM), read only memory (ROM), or other electronic, optical, magnetic or any other computer readable medium.

The controller may further include, in addition to a processor and nonvolatile memory, one or more input and/or output (I/O) device interface(s) that are communicatively coupled via an onboard (local) interface to communicate among other devices. The onboard interface may include, for example but not limited to, an onboard system bus, including a control bus (for inter-device communications), an address bus (for physical addressing) and a data bus (for transferring data). That is, the system bus may enable the electronic communications between the processor, memory and I/O connections. The I/O connections may also include wired connections and/or wireless connections identified herein. The onboard interface may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers to enable electronic communications. The memory may execute programs, access data, or lookup charts, or a combination of each, in furtherance of its processing, all of which may be stored in advance or received during execution of its processes by other computing devices, e.g., via a cloud service or other network connection identified herein with other processors.

Embodiments can be in the form of processor-implemented processes and devices for practicing those processes, such as processor. Embodiments can also be in the form of computer code based modules, e.g., computer program code (e.g., computer program product) containing instructions embodied in tangible media (e.g., non-transitory computer readable medium), such as floppy diskettes, CD ROMs, hard drives, on processor registers as firmware, or any other non-transitory computer readable medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes a device for practicing the embodiments. Embodiments can also be in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes a device for practicing the exemplary embodiments.

Claim 1:
A system (<NUM>) for storing and sharing elevator trips, comprising:
a controller (<NUM>);
a database (<NUM>) operationally coupled to the controller (<NUM>);
an elevator car (<NUM>) in electronic communication with the controller (<NUM>) and operationally located at a first location (<NUM>);
a network (<NUM>) in electronic communication with the controller (<NUM>);
a blockchain (<NUM>) implemented on the network (<NUM>),
wherein the controller (<NUM>) is configured to:
store on the database (<NUM>), ride detail information indicative of an elevator ride experience of a passenger (<NUM>, <NUM>) onboard the elevator car (<NUM>); and
characterised in that the controller (<NUM>) is configured to:
generate a nonfungible token (<NUM>) linked to the ride detail information;
upload the nonfungible token (<NUM>) to the blockchain (<NUM>); and
provide the nonfungible token (<NUM>) to a nonfungible token wallet (<NUM>) on a mobile phone (<NUM>, <NUM>).