Cloud-based sharing of digital keys

Abstract

A system for managing an access to an asset (106, 108) is provided. A digital key to the asset (106, 108) is generated and synchronized between a first user device (104a) of a first user (102a) and an access control device (110a, 110b) that controls the access to the asset (106, 108). A key-sharing request is initiated by the first user device (104a) to grant a second user (102b) the access to the asset (106, 108). Based on the key-sharing request, a server (112) communicates the digital key to a second user device (104b) of the second user (102b). When the second user device (104b) is within a detection range of the access control device (110a, 110b), the access control device (110a, 110b) receives the digital key from the second user device (104b), validates the digital key, and grants the second user (102b) the access to the asset (106, 108) for an access duration defined in the key-sharing request.

Description

BACKGROUNDFIELD OF THE DISCLOSUREVarious embodiments of the disclosure relate generally to access management for assets. Morespecifically, various embodiments of the disclosure relate to methods and systems for cloud-basedsharing of digital keys to access assets.DESCRIPTION OF THE RELATED ARTThroughout human history, assets such as vehicles, storage facilities, or homes have been securedby way of a lock and a key. Advancements in technology have led to the development of modernsecurity systems for securing these assets. These modern security systems enable users to usedigital or virtual keys to access these assets. A digital key is a digital code (e.g., a numeric oralphanumeric code) that may be stored in a user device such as a smartphone or a smartwatch. Asecurity system may allow a user to access an asset (e.g., a vehicle) when a correct digital key ispresented by the user device to the security system. For example, modern-day vehicles are suppliedwith smart key fobs. A smart key fob may communicate with a security system in a vehicle toautomatically unlock the doors of the vehicle when a user, carrying the smart key fob, is near thevehicle. When near the vehicle, the smart key fob communicates a corresponding digital key to thesecurity system in the vehicle, prompting the security system to unlock the doors of the vehicle.In many situations, a user may intend to allow another user to temporarily access an asset. Forexample, a user may want to allow an acquaintance to briefly enter his vehicle to retrieve an item.Similarly, the user may want to allow a plumber to enter his house to perform repairs. If the useris present at a location close to the asset, the user may be available to unlock the asset for accessby other users. However, if the user is at a location away from the asset, the user may beunavailable to unlock the asset for other users. One solution is for the user to share the digital key.But this poses significant security risks for the user.Limitations and disadvantages of conventional and traditional approaches will become apparent toone of skill in the art, through comparison of described systems with some aspects of the presentdisclosure, as set forth in the remainder of the present application and with reference to thedrawings.SUMMARYMethods and systems for cloud-based sharing of digital keys are provided substantially as shownin, and described in connection with, at least one of the figures.These and other features and advantages of the present disclosure may be appreciated from areview of the following detailed description of the present disclosure, along with theaccompanying figures in which like reference numerals refer to like parts throughout.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram that illustrates a system environment for facilitating cloud-based sharingof digital keys, in accordance with an exemplary embodiment of the present disclosure;FIG. 2 is a block diagram that illustrates an application server of FIG. 1, in accordance with anexemplary embodiment of the present disclosure;FIGS. 3A-3E, are diagrams, which collectively, represents a process flow diagram that illustratesa process for facilitating the cloud-based sharing of the digital keys, in accordance with anexemplary embodiment of the disclosure;FIGS. 4A-4C are diagrams, which collectively, represents an exemplary scenario that illustratesuser interface screens rendered on a user device of FIG. 1 for facilitating the cloud-based sharingof the digital keys, in accordance with an exemplary embodiment of the present disclosure; andFIG. 5 is a flow chart that illustrates a method for facilitating the cloud-based sharing of the digitalkeys, in accordance with an exemplary embodiment of the present disclosure.DETAILED DESCRIPTION OF EMBODIMENTSCertain embodiments of the disclosure may be found in disclosed systems and methods for cloudbasedsharing of digital keys. Exemplary aspects of the disclosure provide an access managementsystem that includes a server and an access control device that may be configured to control anaccess to an asset associated with a first user. The server may be configured to receive, from a firstuser device of the first user, a key-sharing request to grant a second user, that is different from thefirst user, the access to the asset. The key-sharing request includes an access duration that isindicative of a time-period for which the asset is to remain accessible to the second user. Based onthe key-sharing request, the server may be further configured to determine a digital key associatedwith the asset and communicate the digital key to a second user device of the second user over acommunication network. Based on the second user device being within a detection range of theaccess control device, the access control device may be configured to receive the digital key fromthe second user device, validate the digital key, and grant, based on the validation of the digitalkey, the second user the access to the asset for the access duration.In some embodiments, the access control device may include a processor, a power source, andcontrol circuitry that may be coupled to the processor and the power source. The processor maybe configured to control the access to the asset. The asset is inaccessible when the processor isdeactivated. The control circuitry may be configured to receive the digital key from the seconduser device, validate the digital key, and activate the processor based on the validation of the digitalkey. The control circuitry activates the processor by coupling the processor to the power source.Further, based on the activation, the processor may be configured to grant the second user theaccess to the asset. The access to the asset corresponds to unlocking the asset.In some embodiments, based on the granted access, the control circuitry may be further configuredto periodically poll the second user device for the digital key. Based on a halt in the reception ofthe digital key from the second user device, the control circuitry may be further configured tocommunicate a shutdown message to the processor. The processor may be further configured toinitiate, based on the shutdown message, a shutdown procedure to lock the asset.In some embodiments, the control circuitry may be further configured to deactivate the processorbased on completion of the shutdown procedure. The control circuitry deactivates the processorby decoupling the processor from the power source.In some embodiments, the asset may include one or more components. The processor may beconfigured to control functioning of the one or more components of the asset to control the accessto the asset. The processor controls the functioning of the one or more components by way of a setof digital keys that is different from the digital key received from the second user device.In some embodiments, the key-sharing request may further include an access code associated withthe first user. The server may be further configured to validate the key-sharing request based onthe access code. Further, the server communicates the digital key to the second user device basedon the validation of the key-sharing request.In some embodiments, the key-sharing request may further indicate a time-window during whichthe access to the asset is to be granted to the second user. The server communicates the digital keyto the second user device at a start of the time-window.In some embodiments, the server may be further configured to communicate an access credentialsdeletion request to the second user device. The server communicates the access credentials deletionrequest based on a lapse of the access duration, an access revocation request generated by the firstuser device to indicate that the access granted to the second user is to be revoked, or a notificationgenerated by the second user device to indicate that the asset is successfully accessed by the seconduser and a distance between the second user device and the access control device is greater thanthe detection range after successfully accessing the asset. Based on the access credentials deletionrequest, the digital key is deleted from the second user device, thereby revoking the access of thesecond user to the asset.In some embodiments, the server may be further configured to receive, from the second userdevice, an extension request to extend the access duration. Further, the server may be configuredto present the extension request to the first user by way of the first user device, and receive, fromthe first user device in response to the extension request, an extension approval message indicatingthat the extension request is approved. The access duration is updated based on an extensionduration indicative of an extended time-period for which the asset is to remain accessible to thesecond user. The extension duration may be included in the extension request or the extensionapproval message. The access control device grants the second user the access to the asset for theupdated access duration.In some embodiments, when the access to the asset is granted to the second user, the first userdevice is beyond the detection range of the access control device.In some embodiments, based on the digital key, the second user is granted access to the asset inentirety.In some embodiments, the asset is divided into a plurality of parts. An access to the plurality ofparts is controlled by way of a plurality of digital keys, respectively. The key-sharing request mayfurther include an access level indicating that the second user is to be granted access to a first partof the asset. The server may be further configured to select, from the plurality of digital keys basedon the access level, the digital key that is associated with the first part of the asset.In some embodiments, the server may be further configured to communicate a user authenticationrequest to the second user device and receive, as a response to the user authentication request, userauthentication data associated with the second user. Further, the server may be configured tovalidate the user authentication data to authenticate the second user. Based on the validation of theuser authentication data, the server communicates the digital key to the second user device or theaccess control device receives the digital key from the second user device.In some embodiments, the access control device is further configured to receive, based on anattempt of the second user to access the asset, user authentication data associated with the seconduser, and validate the user authentication data to authenticate the second user. The access controldevice grants the second user the access to the asset further based on the validation of the userauthentication data.In some embodiments, the digital key is synchronized between the first user device and the accesscontrol device prior to the server receiving the key-sharing request from the first user device basedon the first user device being within the detection range of the access control device. The servermay be further configured to receive, from the first user device, a first time-stamp indicative of atime-instance at which the digital key is synchronized between the first user device and the accesscontrol device and a validity period of the digital key. When the key-sharing request is received,the server may be further configured to determine, based on the validity period and the first timestamp,a remaining validity of the digital key and compare the access duration with the remainingvalidity of the digital key. The server communicates the digital key to the second user device basedon the remaining validity of the digital key being greater than the access duration by a predeterminedthreshold.In some embodiments, the access control device may be further configured to generate the digitalkey and synchronize the digital key with the first user device based on the first user device beingwithin the detection range of the access control device. The digital key is synchronized betweenthe first user device and the access control device prior to the server receiving the key-sharingrequest from the first user device. The server may be further configured to receive the digital keyfrom the first user device as a part of the key-sharing request or when the digital key issynchronized.In some embodiments, the digital key is generated by the first user device. The access controldevice may be further configured to receive, based on the first user device being within thedetection range of the access control device, the digital key from the first user device tosynchronize the digital key therebetween. The digital key is synchronized between the first userdevice and the access control device prior to the server receiving the key-sharing request from thefirst user device. The server may be further configured to receive the digital key from the first userdevice as a part of the key-sharing request or when the digital key is generated by the first userdevice.In some embodiments, the server may be further configured to generate the digital key andcommunicate the digital key to the first user device. The access control device may be furtherconfigured to receive, based on the first user device being within the detection range of the accesscontrol device, the digital key from the first user device to synchronize the digital keytherebetween. The digital key is synchronized between the first user device and the access controldevice prior to the server receiving the key-sharing request from the first user device.In some embodiments, the key-sharing request may further include an identifier of the second user.The server may be further configured to determine the second user to whom the access is to begranted and the second user device associated with the second user based on the key-sharingrequest.In some embodiments, based on the key-sharing request, the server may be further configured toselect the second user and present the selected second user to the first user by way of the first userdevice. The server may be further configured to receive a user approval message from the firstuser device indicating that the second user is approved for the access to the asset. Further, theserver may be configured to determine the second user device associated with the second user forcommunicating the digital key.FIG. 1 is a block diagram that illustrates a system environment 100 for facilitating cloud-basedsharing of digital keys, in accordance with an exemplary embodiment of the present disclosure.The system environment 100 includes first and second users 102a and 102b that are associatedwith first and second user devices 104a and 104b, respectively. Hereinafter, the first and secondusers 102a and 102b are collectively referred to and designated as "a set of users 102" and the firstand second user devices 104a and 104b are collectively referred to and designated as "a set of userdevices 104". The system environment 100 further includes a vehicle 106 and a facility 108 thatare associated with the first user 102a. Further, the system environment 100 includes first andsecond access control devices 110a and 110b that control access to the vehicle 106 and the facility108, respectively, and an application server 112. The first and second access control devices 110aand 110b and the application server 112 correspond to an access management system that managesaccess to an asset (such as the vehicle 106 and the facility 108).The application server 112 and the first and second user devices 104a and 104b may communicateby way of a communication network 114. The communication network 114 may include suitablelogic, circuitry, interfaces, and / or code, executable by the circuitry, that may be configured totransmit queries, messages, data, and requests between various entities, such as the set of userdevices 104 and the application server 112. Examples of the communication network 114 mayinclude, but are not limited to, a wireless fidelity (Wi-Fi) network, a light fidelity (Li-Fi) network,a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), asatellite network, the Internet, a fiber-optic network, a coaxial cable network, an infrared (IR)network, a radio-frequency (RF) network, and a combination thereof. Various entities in thesystem environment 100 may be coupled to the communication network 114 in accordance withvarious wired and wireless communication protocols, such as Transmission Control Protocol andInternet Protocol (TCP / IP), User Datagram Protocol (UDP), Long Term Evolution (LTE)communication protocols, or any combination thereof.The first user device 104a may include suitable logic, circuitry, interfaces, and / or code, executableby the circuitry, that enables sharing of digital keys associated with various assets (e.g., the vehicle106 and the facility 108) with other user devices. In other words, the first user device 104a mayenable the first user 102a to share (e.g., transmit or receive), with other users (e.g., the second user102b), digital keys to access various assets. For the sake of brevity, the term "key" refers to digitalkeys throughout the disclosure. A digital key may be a digital code (e.g., a numeric code, analphanumeric code, or the like) that grants, a user or a user device, access to an asset (e.g., thevehicle 106 or the facility 108). The first user device 104a may be configured to execute a serviceapplication 116, hosted by the application server 112, for a purpose of sharing digital keys. In oneembodiment, the service application 116 may be a stand-alone application installed on the firstuser device 104a. In another embodiment, the service application 116 may be a web-basedapplication that is accessible through a browser application installed on the first user device 104a.Examples of the first user device 104a may include, but are not limited to, smartphones,smartwatches, tablets, phablets, laptops, or the like. It will be apparent to those of skill in the artthat the second user device 104b that is associated with the second user 102b may be functionallysimilar to the first user device 104a. The second user device 104b is also configured to execute theservice application 116.The vehicle 106 is a mode of transport that is utilized by the first user 102a to commute from onelocation to another location. In one embodiment, the vehicle 106 is privately owned by the firstuser 102a and may be used for fulfilling self-traveling requirements. In another embodiment, thevehicle 106 may be deployed by a service provider, such as a transport aggregator, to provide on-demand vehicle services to one or more users. The vehicle 106 may include, therein, a plurality ofvehicular systems. The plurality of vehicular systems may include, but are not limited to, a doorlocking / unlocking system, a boot lid locking / unlocking system, a fuel-port lid locking / unlockingsystem, a charging-port locking / unlocking system, an air-conditioning system, an in-carentertainment system, an electrical system, or the like. The vehicle 106 may be one of an electricvehicle, an internal combustion engine vehicle, a hybrid vehicle, or the like. The vehicle 106 (e.g.,the plurality of vehicular systems in the vehicle 106) may be accessed by way of a digital keyassociated with the vehicle 106. Examples of the vehicle 106 may include, but are not limited to,two-wheelers (e.g., bikes), three-wheelers, four-wheelers (e.g., cars, trucks, buses, or the like).Access to the vehicle 106 is controlled (e.g., regulated) by the first access control device 110a.The first access control device 110a is a security system that may permit a user to access the vehicle106 (e.g., access one or more of the plurality of vehicular systems), based on whether the digitalkey to the vehicle 106 is stored in a user device of the user. The access to the vehicle 106 maycorrespond to unlocking a set of doors of the vehicle 106, unlocking a boot-lid of the vehicle 106,or the like. The first access control device 110a may be installed at various locations in the vehicle106. For example, the first access control device 110a may be installed on top of a dashboard inthe vehicle 106, within the dashboard, on an inside portion of a door of the vehicle 106, on anoutside portion of a door of the vehicle 106, or the like.The first access control device 110a may be configured to wirelessly communicate with userdevices. Wireless communication may be established between the first access control device 110aand a user device (e.g., the first user device 104a) if the user device is present within a detectionrange of the first access control device 110a. In other words, wireless communication may beestablished between the first access control device 110a and the user device if a distance betweenthe user device and the first access control device 110a is below a threshold. For the sake of brevity,the term "detection range" is interchangeably referred to as a "threshold distance" throughout thedisclosure. Therefore, wireless communication may be established between the first access controldevice 110a and the user device when the user device is within the threshold distance of the firstaccess control device 110a. The threshold distance may vary depending on a type of wirelesscommunication used by the first access control device 110a. Examples of the type of wirelesscommunication that may be used or supported by the first access control device 110a include, butare not limited to, RF communication, near-field communication (NFC), Bluetooth low-energy(BLE), Wi-Fi, or the like.The digital key that may be stored in the user device (e.g., the first user device 104a) of a user(e.g., the first user 102a) enables the user to access one or more functions or components (e.g., theplurality of vehicular systems) of the vehicle 106. For example, if the digital key to the vehicle106 is stored in the first user device 104a, the set of doors of the vehicle 106 may be automaticallyunlocked when the first user 102a, carrying the first user device 104a, approaches the vehicle 106or when the first user 102a places his hand on a door handle of one of the set of doors. Similarly,the boot-lid of the vehicle 106 may be automatically unlocked for the first user 102a carrying thefirst user device 104a when the first user 102a approaches a rear of the vehicle 106 or when thefirst user 102a places his hand on the boot lid of the vehicle 106. Similarly, the first user 102a mayaccess other functions or components of the vehicle 106 (e.g., a fuel-port of the vehicle 106 or acharging-port of the vehicle 106) based on whether the digital key is stored in the first user device104a. Further, the vehicle 106 may be switched on and / or driven by the first user 102a based onwhether the digital key is stored in the first user device 104a that is carried by the first user 102a.The first access control device 110a may include a processor 118, control circuitry 120, a powersource 122, and a first network interface 124.The processor 118 may include suitable logic, circuitry, interfaces, and / or code, executable by thecircuitry, that may be configured to control or regulate access to the vehicle 106. In other words,the processor 118 may be configured to control a functioning of the plurality of vehicular systemsin the vehicle 106. For example, the processor 118 may control a set of motors included in the doorlocking / unlocking system for locking / unlocking the set of doors of the vehicle 106. The processor118 may further control circuits or components responsible for starting an engine in the vehicle106, driving a starter motor in the vehicle 106, and / or one or more accessories (e.g., an airconditioner,a music system, a multi-information display, a touchscreen console) in the vehicle106. In one embodiment, the first access control device 110a (e.g., the processor 118) may store,therein, a set of primary digital keys. The primary digital keys may be provided by an originalequipment manufacturer of the vehicle 106 and may not be shared with the first user device 104aand the application server 112. For example, the set of primary digital keys may include first andsecond primary digital keys for locking and unlocking the set of doors of the vehicle 106,respectively. Similarly, the set of primary digital keys may include third and fourth primary digitalkeys for locking and unlocking the boot lid of the vehicle 106. It will be apparent to those of skillin the art that the set of primary digital keys may include other primary digital keys associated withthe plurality of vehicular systems. The processor 118 may use the set of primary digital keys forcontrolling access to the plurality of vehicular systems in the vehicle 106. Examples of theprocessor 118 may include, but are not limited to, an application-specific integrated circuit (ASIC)processor, a reduced instruction set computer (RISC) processor, a complex instruction setcomputer (CISC) processor, a field-programmable gate array (FPGA), and the like.The control circuitry 120 may include suitable logic, circuitry, interfaces, and / or code, executableby the circuitry, that may be configured to generate passcodes (e.g., secondary digital keysassociated with the vehicle 106) for accessing the vehicle 106. A generated passcode may be arandom digital code such as a 128-bit code, a 256-bit code, or the like. For the sake of brevity, theterm "secondary digital key" is interchangeably referred to as "passcode" throughout thedisclosure. The passcode generated by the control circuitry 120 may be wirelessly transmitted orcommunicated, by way of the first network interface 124, to the first user device 104a when thefirst user device 104a is within the threshold distance of the first access control device 110a.Wireless communication between the first user device 104a and the first access control device110a may take place by way of RF signals (e.g., radio waves). In a non-limiting example, NFC isused for wireless communication. However, in various other embodiments, other wirelesscommunication techniques or methods such as Wi-Fi, BLE, or the like may be used.Prior to the transmission of the passcode to the first user device 104a, the control circuitry 120may acquire and ascertain an identity of the first user device 104a to ensure that the first userdevice 104a is an intended recipient of the passcode. For example, the control circuitry 120 (e.g.,the first access control device 110a) may request the first user device 104a to provide an identifierof the first user device 104a. Based on the request, the first user device 104a may communicatethe identifier of the first user device 104a to the first access control device 110a. The controlcircuitry 120 may compare the identifier received from the first user device 104a to a unique knownidentifier of the first user device 104a that may be stored in the control circuitry 120 or a storagecircuit (not shown) in the first access control device 110a. If the received identifier and the knownidentifier match, the control circuitry 120 may communicate the passcode to the first user device104a. It will be apparent to those of skill in the art the transmission of the passcode to the first userdevice 104a may take place when the first user device 104a is within the threshold distance of thefirst access control device 110a. Examples of the identifier of the first user device 104a mayinclude, but are not limited to, a unique identifier of a first NFC tag included in the first user device104a, a unique identifier of an RF tag included in the first user device 104a, an internal mobileequipment identity (IMEI) number of the first user device 104a, or the like.The generated passcode may be suitably encrypted, by the control circuitry 120, before thegenerated passcode is transmitted to the first user device 104a. Further, the transmission of thepasscode may be secured by using various techniques such as adding pseudorandom noise to RFsignals used for the transmission. Methods of securely transferring data and encrypting anddecrypting sensitive information or signals are well-known to those of skill in the art. It will beapparent to those of skill in the art that all communication between the first access control device110a and the set of user devices 104 may be encrypted to mitigate security risks. The first userdevice 104a may store, therein, the passcode received from the first access control device 110a(e.g., the control circuitry 120). For example, the first user device 104a may write the receivedpasscode to the first NFC tag included in the first user device 104a. In other words, the first NFCtag in the first user device 104a stores the passcode. The passcode may thus be synchronizedbetween the first access control device 110a and the first user device 104a.The control circuitry 120 may be further configured to control a power supply to the processor118. The processor 118 draws power from the power source 122 (e.g., a battery) by way of thecontrol circuitry 120. In other words, the processor 118 is coupled to the power source 122 by wayof the control circuitry 120. It will be apparent to those of skill in the art that the power source 122may include all sources of alternating current (AC) and direct current (DC) voltages, such as, butnot limited to, mains electricity, batteries, or the like. In a non-limiting example, the power source122 is a 2-3.3 Volt (V) battery.The control circuitry 120 may enable the processor 118 to be switched on or off. In oneembodiment, the processor 118 may be switched on or off (e.g., activated or deactivated), bycontrolling a position of a relay (not shown) included in the control circuitry 120. For example,when the relay is in an "OPEN" position, a connection between the processor 118 and the powersource 122 is incomplete, thereby disconnecting (e.g., decoupling) the processor 118 from thepower source 122 and rendering the processor 118 deactivated. Similarly, when the relay is in a"CLOSED" position, a connection between the processor 118 and the power source 122 iscomplete, thereby connecting (e.g., coupling) the processor 118 to the power source 122 andrendering the processor 118 active. In one embodiment, the vehicle 106 may be inaccessible whenthe processor 118 is switched off (e.g., in a power-down state). In other words, the set of doors ofthe vehicle 106, the boot lid of the vehicle 106, the fuel-port lid of the vehicle 106, or the like, maybe shut or locked when the processor 118 is switched off. The relay included in the control circuitry120 may be "normally OPEN". The control circuitry 120 may actuate the relay (e.g., move therelay to the "CLOSED" position) when a user device (e.g., the first user device 104a) that is withinthe threshold distance of the first access control device 110a communicates a correct passcode tothe control circuitry 120. The control circuitry 120 may validate the received passcode bycomparing the received passcode with the passcode stored in the control circuitry 120. If thepasscode is successfully validated, the control circuitry 120 actuates the relay, and power issupplied from the power source 122 to the processor 118, switching on or powering on theprocessor 118.The first network interface 124 may include suitable logic, circuitry, interfaces, and / or code,executable by the circuitry, that may be configured to facilitate communication with user devices(e.g., the set of user devices 104). The first network interface 124 may also facilitate internalcommunication between components (e.g., the processor 118, the control circuitry 120, or the like)included in the first access control device 110a. The first network interface 124 may furtherfacilitate communication between the first access control device 110a and other vehicularcomponents (e.g., the set of motors) present in the vehicle 106. Examples of the first networkinterface 124 may include, but are not limited to, an antenna, an RF transceiver, a wirelesstransceiver, a Bluetooth transceiver, an ethernet port, a universal serial bus (USB) port, or anyother device configured to transmit and receive data.In one embodiment, the passcode may be valid only for a limited period of time. For example, thepasscode may be valid for a time-period of "7" hours. After "7" hours from a time ofsynchronization between the first access control device 110a (e.g., the control circuitry 120) andthe first user device 104a, a new passcode may be generated by the control circuitry 120. However,the new passcode may be used for accessing the vehicle 106 only after the new passcode issynchronized with the first user device 104a. The new passcode may be synchronized with the firstuser device 104a, whenever the first user device 104a is within a threshold distance of the firstaccess control device 110a.In one embodiment, based on the identifier of the first user device 104a, the first access controldevice 110a may recognize the first user device 104a as a trusted or primary device associatedwith the vehicle 106. Therefore, whenever the first user device 104a is within the thresholddistance of the first access control device 110a, the first access control device 110a maysynchronize a latest generated passcode with the first user device 104a. For example, when thefirst access control device 110a receives a valid passcode (e.g., the secondary digital key) from thefirst user device 104a that is within the threshold distance, the first access control device 110a maycommunicate the second primary digital key to the set of motors for unlocking the set of doors ofthe vehicle 106 for the first user 102a. For the sake of brevity, the term "set of doors" isinterchangeably referred to as "doors" throughout the disclosure.The facility 108 may be a warehouse, a storeroom, a distribution center, a residential premise, anoffice, or the like associated with the first user 102a. The facility 108 may be associated with adigital key that enables access to the facility 108. Access to the facility 108 is controlled by thesecond access control device 110b. It will be apparent to those of skill in the art that the secondaccess control device 110b may be functionally similar to the first access control device 110a. Thesecond access control device 110b may control or regulate access to the facility 108 in a similarmanner as described above.The application server 112 may include suitable logic, circuitry, interfaces, and / or code, executableby the circuitry, that may be configured to facilitate sharing of the secondary digital keys betweenuser devices (e.g., the first and second user devices 104a and 104b). The application server 112hosts the service application 116 that is executed on the set of user devices 104. Further, theapplication server 112 offers a cloud-based key-sharing service that enables users to share keys toaccess various assets (e.g., the vehicle 106 and the facility 108). The cloud-based key-sharingservice may be available to users that are registered with the application server 112 (e.g., theservice application 116). For the sake of brevity, the term "cloud-based key-sharing service" isinterchangeably referred to as "key-sharing service" throughout the disclosure. Examples of theapplication server 112 may include, but are not limited to, a personal computer, a laptop, a mini-computer, a mainframe computer, a cloud-based server, a network of computer systems, or a nontransientand tangible machine executing a machine-readable code.In operation, a user (e.g., the set of users 102) intending to use the service application 116 forproviding or receiving access (e.g., sharing keys) to an asset (e.g., the vehicle 106) may initiate aregistration process for registering with the service application 116. For example, upon aninstallation of the service application 116 on the first user device 104a, the service application 116may prompt the first user 102a to register or sign-up for the key-sharing service. In other words,the first user 102a may be prompted to create a first set of login credentials (e.g., a username anda password) for accessing / using the service application 116. Following the entering of the logincredentials by the first user 102a, the service application 116 may request or prompt the first user102a to enter information (e.g., vehicle information) of one or more assets (e.g., the vehicle 106and the facility 108) to be enrolled for the key-sharing service. For the sake of brevity, the currentembodiment is described in regard to the vehicle 106. It will be apparent to those of skill in the artthat key-sharing for the facility 108 may proceed in a similar fashion.Vehicle information of the vehicle 106 may be entered by the first user 102a in the serviceapplication 116. Examples of the vehicle information may include, but are not limited to, a vehicleidentification number (VIN) of the vehicle 106, a registration number of the vehicle 106, a chassisnumber of the vehicle 106, a make and model of the vehicle 106, a color of the vehicle 106, a nameof an owner of the vehicle 106, or the like. In some embodiments, the service application 116 mayfurther prompt the first user 102a to enter his / her contact details (e.g., a phone number or an emailaddress) and a third-party access code (e.g., a personal identification number) for authenticatingor validating key-sharing requests initiated by the first user 102a. The application server 112 maystore, therein, the contact details and the login credentials of the first user 102a, the third-partyaccess code, and the vehicle information of the vehicle 106.The second user 102b may also register with the service application 116 in a similar manner.However, for the sake of brevity, it is assumed that the second user 102b does not wish to enrollany of his assets for the key-sharing service, and, therefore, enters only his login credentials andcontact details. The login credentials and the contact details of the second user 102b may be storedby the application server 112. Thus, the first and second users 102a and 102b are registered withthe application server 112 for availing the key-sharing service.The first access control device 110a (e.g., the control circuitry 120) may generate a first passcodethat is to be used for accessing the vehicle 106. Upon the generation of the first passcode, the firstaccess control device 110a may communicate the first passcode to the first user device 104a. Thefirst passcode is thus synchronized between the first access control device 110a and the first userdevice 104a. In a non-limiting example, the first NFC tag included in the first user device 104astores the first passcode received from the first access control device 110a. In one embodiment,the service application 116 being executed on the first user device 104a may be provided requisitepermissions or rights by the first user 102a to retrieve a latest passcode stored in the first NFC tag.In such a scenario, the service application 116 may always store, therein, the latest passcodesynchronized between the first user device 104a and the first access control device 110a. However,in another embodiment, the service application 116 may not have the requisite permissions to readdata stored in the first NFC tag. In such a scenario, the service application 116 may retrieve thepasscode from the first NFC tag (e.g., read the first NFC tag) only when a temporary permissionis granted by the first user 102a and / or when a key-sharing request is raised by the first user 102a.For the sake of brevity, it is assumed that the service application 116 is granted the requisitepermissions or rights to always retrieve the latest passcode stored in the first NFC tag. The firstpasscode is thus further synchronized between the first user device 104a and the application server112 by way of the service application 116.The first user 102a may intend to grant access rights to the second user 102b for accessing thevehicle 106. Granting access rights to the second user 102b for accessing an asset (e.g., the vehicle106) may be defined as sharing, with the second user 102b, a secondary digital key to the asset. Inother words, the first user 102a may intend to share, with the second user 102b, the secondarydigital key (e.g., the first passcode) to the vehicle 106. In a non-limiting example, the second user102b may be an acquaintance of the first user 102a, and may wish to retrieve an item that was leftbehind in the vehicle 106. In such a scenario, the first user 102a may use the service application116 to enable the second user 102b to access the vehicle 106. It is assumed, for the sake of brevity,that the first passcode stored in the first NFC tag is a latest passcode synchronized between thefirst user device 104a and the first access control device 110a.For granting access rights to the second user 102b, a key-sharing request may be initiated by thefirst user 102a by way of the service application 116. The key-sharing request is a request forgranting access rights to the second user 102b for accessing the vehicle 106. In other words, thekey-sharing request is a request for sharing the secondary digital key of the vehicle 106 with thesecond user 102b. The key-sharing request may include an identifier (e.g., the contact details) ofthe second user 102b for uniquely identifying the second user 102b as an intended recipient of thesecondary digital key of the vehicle 106. In some cases, the key-sharing request may furtherinclude an access duration (e.g., "25" minutes) defined by the first user 102a. The access durationmay indicate a total time-period for which the vehicle 106 is to remain accessible to the seconduser 102b from a time-instant at which the vehicle 106 is accessed by the second user 102b. Thekey-sharing request may also include the third-party access code that may be entered by the firstuser 102a when the first user 102a initiates the key-sharing request. In scenarios where the firstuser 102a has enrolled multiple assets to the key-sharing service, the key-sharing request mayfurther include a selection, by the first user 102a, of an asset (e.g., the vehicle 106) for which accessrights are to be shared.Upon receiving the key-sharing request from the first user device 104a, the application server 112may authenticate or validate the key-sharing request based on the third-party access code includedin the key-sharing request. Consequently, the application server 112 may identify the second user102b as the intended recipient of access rights to the vehicle 106, based on the identifier (e.g., thecontact details) of the second user 102b that is included in the key-sharing request. The applicationserver 112 may further identify the second user device 104b that is associated with the second user102b. Further, based on the key-sharing request, the application server 112 may communicate aset of access credentials to the second user device 104b. The set of access credentials may includethe first passcode and the access duration. The application server 112 may further communicate,to the second user device 104b, details (e.g., the vehicle information) of the vehicle 106. Theservice application 116, being executed on the second user device 104b, may write the firstpasscode to a second NFC tag included in the second user device 104b. The service application116 may display, on a display screen of the second user device 104b, the access duration and thedetails of the vehicle 106.The vehicle 106 may be consequently approached by the second user 102b carrying the seconduser device 104b. When the second user device 104b is within the threshold distance of the firstaccess control device 110a (e.g., when a connection is established between the control circuitry120 and the second user device 104b), the control circuitry 120 may receive an access request foraccessing the vehicle 106 from the second user device 104b. The access request may be an RFsignal that includes the first passcode and an identifier of the second user device 104b. The accessrequest may further include the access duration. Examples of the identifier of the second userdevice 104b may include, but are not limited to, an identifier of the second NFC tag, an identifierof a second RF chip included in the second user device 104b, an IMEI number of the second userdevice 104b, or the like.The control circuitry 120 may determine that a user different from the first user 102a is attemptingto access the vehicle 106, based on a mismatch between the identifier of the second user device104b and the identifier of the first user device 104a that is stored in the control circuitry 120. Basedon the determination that a user different from the first user 102a is attempting to access the vehicle106, any new passcode generated by the first access control device 110a may not be transmitted toor synchronized with the second user device 104b. The control circuitry 120 may then compare apasscode (e.g., the first passcode) included in the access request with the first passcode stored inthe control circuitry 120. The control circuitry 120 may determine that the passcode included inthe access request matches the first passcode stored in the control circuitry 120. Consequently, thecontrol circuitry 120 actuates the relay, moving the relay to the "CLOSED" position, thereby,enabling the supply of power from the power source 122 to the processor 118. Thus, the processor118 is switched or powered on.Based on the successful validation of the first passcode included in the access request, theprocessor 118 may provide the second user 102b access to the vehicle 106. For example, theprocessor 118 may actuate the set of motors that control the locking / unlocking of the doors, therebyunlocking the doors of the vehicle 106. The processor 118 may actuate the set of motors using thesecond primary digital key. When the doors of the vehicle 106 are unlocked, the first access controldevice 110a (e.g., the control circuitry 120) may communicate, to the second user device 104b, amessage (e.g., notification) indicating that the doors of the vehicle 106 are now unlocked (e.g.,access is approved for the second user 102b). The service application 116 being executed on thesecond user device 104b may display the message on the display screen of the second user device104b. Further, the service application 116 may communicate the message to the application server112. The message may further indicate a time-stamp of a time-instance (e.g., 5:35 pm, 22nd May)at which the doors were unlocked for the second user 102b. Further, the application server 112may communicate the message to the first user device 104a. The service application 116 on thefirst user device 104a may display the notification on a display screen of the first user device 104a.The unlocked doors of the vehicle 106 may be opened by the second user 102b and the item maybe retrieved from the vehicle 106 by the second user 102b within the access duration. The doorsof the vehicle 106 may then be shut by the second user 102b, and the second user 102b may walkaway from the vehicle 106. When the second user 102b leaves the threshold distance of the firstaccess control device 110a, the first access control device 110a does not detect the RF signal thatwas being transmitted by the second user device 104b. Therefore, the control circuitry 120 movesback to the "OPEN" position from the "CLOSED" position, powering down the processor 118.Before powering down, the processor 118 may communicate one or more commands (e.g., thefirst primary digital key) to the set of motors for locking the doors of the vehicle 106.When the second user device 104b is no longer connected to the first access control device 110a,the service application 116 on the second user device 104b may communicate a notification to theapplication server 112, indicating that the second user 102b has exited the vehicle 106. Theapplication server 112 may communicate, to the first user device 104a, the notification indicatingthat the second user 102b has exited the vehicle 106. The service application 116 on the first userdevice 104a may display the notification on the display screen of the first user device 104a. Further,based on the notification, the application server 112 may revoke the access rights of the seconduser 102b to the vehicle 106. The application server 112 may communicate an access credentialsdeletion request to the second user device 104b. Based on the access credentials deletion request,the service application 116 may delete the first passcode from the second NFC tag in the seconduser device 104b. Based on the deletion of the first passcode, the service application 116 on thesecond user device 104b may communicate an access credentials deletion response to theapplication server 112, indicating that the first passcode is deleted from the second user device104b. Consequently, the application server 112 may communicate, to the first user device 104a, amessage indicating that the access rights of the second user 102b to the vehicle 106 have beenrevoked. In another embodiment, the application server 112 may revoke the access rights of thesecond user 102b only upon expiry of the access duration. The process of key-sharing and accesscontrol is explained in conjunction with FIGS. 3A-3E.In another embodiment, passcodes (e.g., the secondary digital keys) for the vehicle 106 may begenerated by the service application 116 running on the first user device 104a. In such scenarios,upon generation of a passcode, the first user device 104a may communicate the passcode to thefirst access control device 110a, when the first user device 104a is within the threshold distance ofthe first access control device 110a. The first access control device 110a may store, therein, thepasscode received from the first user device 104a, thereby synchronizing the passcode betweenthe first access control device 110a and the first user device 104a. The first user device 104a mayfurther synchronize the generated passcode with the application server 112.In another embodiment, passcodes for the vehicle 106 may be generated by the application server112. In such a scenario, a passcode generated by the application server 112 may be communicatedto the first user device 104a, which, in turn, synchronizes the passcode with the first access controldevice 110a.In another embodiment, the system environment 100 may further include another portable device(e.g., an access card; not shown) associated with the first user 102a. The first access control device110a may be configured to recognize the portable device, in addition to the first user device 104a,as a trusted device associated with the vehicle 106 and / or the first user 102a. The first accesscontrol device 110a may communicate, to the portable device, any passcode (e.g., the firstpasscode) generated by the first access control device 110a. In other words, any passcode generatedby the first access control device 110a may be synchronized with the portable device, provided theportable device is within the threshold distance of the first access control device 110a. The portabledevice may be used by the first user 102a to access the vehicle 106, in lieu of the first user device104a. Further, the portable device may be capable of synchronizing passcodes with the first userdevice 104a.FIG. 2 is a block diagram that illustrates the application server 112, in accordance with anexemplary embodiment of the present disclosure. The application server 112 may includeprocessing circuitry 202, a memory 204, and a second network interface 206. The processingcircuitry 202, the memory 204, and the second network interface 206 may communicate with eachother by way of a communication bus 208.The processing circuitry 202 may include suitable logic, circuitry, interfaces, and / or code,executed by the circuitry, to facilitate cloud-based key-sharing. The processing circuitry 202 maybe configured to receive key-sharing requests from the user and grant access rights to users, basedon the received key-sharing requests. Examples of the processing circuitry 202 may include, butare not limited to, an ASIC processor, a RISC processor, a CISC processor, an FPGA, and the like.The processing circuitry 202 may include an application host 210 and an access managementengine 212, and may execute various operations for facilitating cloud-based key-sharing by wayof the application host 210 and the access management engine 212.The application host 210 may host the service application 116 that enables the set of users 102 toavail the key-sharing service. The application host 210 may receive, from user devices (e.g., thefirst user device 104a), key-sharing requests for sharing secondary digital keys to access variousassets. The application host 210 may further receive from the user devices, the secondary digitalkeys (e.g., the first passcode) that are stored in the user devices.The access management engine 212 may manage sharing of access rights with users, based on thekey-sharing requests received by the application host 210. Based on the key-sharing requests, theaccess management engine 212 may grant users (e.g., the second user 102b), temporary accessrights to access various assets (e.g., the vehicle 106). The access management engine 212 maycommunicate, to user devices of these users, access credentials (e.g., the set of access credentials)required for accessing the various assets. Further, the access management engine 212, whenrequired, may initiate deletion of the access credentials stored in the user devices.The memory 204 may include suitable logic, circuitry, interfaces, and / or code, executable by thecircuitry, to store information required for facilitating cloud-based key-sharing. The memory 204may include a database 214 that stores, therein, login credentials (e.g., username and password)and contact details (e.g., email address, phone number, or the like) of users (e.g., the first user102a) registered with the application server 112 for the key-sharing service. The database 214 mayfurther store, therein, details of assets (e.g., the vehicle information of the vehicle 106) enrolled bythe registered users for the key-sharing service. Further, the database 214 may store, therein,passcodes (e.g., the first passcode) retrieved from user devices (e.g., the first user device 104a).The database 214 may further store validity periods and time-stamps associated with thepasscodes. Additionally, the database 214 may store key-sharing data which may include, but isnot limited to, details of recipients (e.g., the second user 102b) who received access rights to anasset, access logs of these recipients (e.g., a time of entry and / or time of exit of the second user102b from the vehicle 106), or the like. Examples of the memory 204 may include a random-accessmemory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD),a flash memory, a solid-state memory, or the like. It will be apparent to a person skilled in the artthat the scope of the disclosure is not limited to realizing the memory 204 in the application server112, as described herein. In another embodiment, the memory 204 may be realized in form of adatabase server or a cloud storage working in conjunction with the application server 112, withoutdeparting from the scope of the disclosure.The second network interface 206 may include suitable logic, circuitry, interfaces, and / or code,executable by the circuitry, to transmit and receive data over the communication network 114using one or more communication network protocols. The second network interface 206 maytransmit requests and messages to and receive requests and messages from the set of user devices104. Examples of the second network interface 206 may include, but are not limited to, an antenna,a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an ethernet port, auniversal serial bus (USB) port, or any other device configured to transmit and receive data.FIGS. 3A-3E, are diagrams, which collectively, represents a process flow diagram 300 thatillustrates a process for facilitating the cloud-based sharing of the digital keys, in accordance withan exemplary embodiment of the disclosure. The process flow diagram 300 is explained inconjunction with FIG. 1. The process flow diagram 300 includes the first access control device110a, the set of user devices 104, and the application server 112. For the sake of brevity, it isassumed that the first and second users 102a and 102b are already registered with the applicationserver 112 for the key-sharing service. It is further assumed that the vehicle 106 is already enrolledfor the key-sharing service.Referring now to FIG. 3A, the first access control device 110a (e.g., the control circuitry 120)generates the first passcode (as shown by arrow 302). The first user device 104a may be within thethreshold distance of the first access control device 110a. Consequently, the first access controldevice 110a (e.g., the control circuitry 120) may communicate (e.g., transmit) the generated firstpasscode to the first user device 104a (as shown by arrow 304), as described in the foregoingdescription of FIG. 1. The first user device 104a may store, therein, the first passcode (as shownby arrow 306). In order to ensure passcode synchronization between the first access control device110a and the first user device 104a, the first user device 104a may transmit or communicate apasscode confirmation message to the first access control device 110a (as shown by arrow 308).The passcode confirmation message may include the first passcode received by the first user device104a and may be received by the control circuitry 120 by way of the first network interface 124,as described in the foregoing description of FIG. 1. Upon receiving the passcode confirmationmessage, the control circuitry 120 may determine whether the first passcode generated / stored bythe control circuitry 120 is the same as the first passcode included within the passcode confirmationmessage (as shown by arrow 310). If the first passcode, included in the passcode confirmationmessage, matches the first passcode that was generated by the control circuitry 120, the controlcircuitry 120 may communicate an acknowledgment message to the first user device 104a (asshown by arrow 312).The acknowledgment message may indicate that the synchronization of the first passcode issuccessful. Further, the acknowledgment message may include a first time-stamp that is indicativeof a time-instance at which the first passcode was synchronized between the first user device 104aand the first access control device 110a. The acknowledgment message may further include avalidity period (e.g., "7" hours) indicating a time-period for which the first passcode is valid. Thefirst passcode may expire when the validity period elapses. The first user device 104a may store,therein, the first time-stamp and the validity period (as shown by arrow 314).If a passcode (e.g., the first passcode) included in the passcode confirmation message does notmatch the first passcode stored by the control circuitry 120, the first access control device 110amay communicate an error message to the first user device 104a, indicating that thesynchronization of the first passcode between the first access control device 110a and the first userdevice 104a has failed. Consequently, the first access control device 110a may generate a newpasscode and / or re-attempt synchronization with the first user device 104a. However, for the sakeof brevity, it is assumed that the first passcode is successfully synchronized between the first userdevice 104a and the first access control device 110a.The service application 116 that is being executed on the first user device 104a may retrieve thefirst passcode, the first time-stamp, and the validity period from the first user device 104a, if theservice application 116 has been granted the requisite permissions or rights by the first user 102a(as shown by arrow 316). The service application 116 may communicate the retrieved firstpasscode, the first time-stamp, and the validity period to the application server 112 (as shown byarrow 318). The application server 112 stores, therein, the first passcode, the first time-stamp, andthe validity period of the first passcode (as shown by arrow 320). The application server 112 maystore, in the database 214, passcodes, time-stamps, and validity periods for each asset enrolled forthe key-sharing service.In another embodiment, the service application 116 may not have the requisite permissions toretrieve passcodes, validity periods, and / or time-stamps from the first user device 104a. In such ascenario, the service application 116 may prompt the first user 102a to provide explicit permissionfor retrieving the passcodes, validity periods, and / or time-stamps when the first user 102a initiatesa key-sharing request by way of the service application 116.Referring now to FIG. 3B, the first user 102a may intend to grant the second user 102b temporaryaccess rights to the vehicle 106. In such a scenario, the first user 102a may be at a remote locationwith respect to the vehicle 106. In other words, a distance between the first user device 104a (e.g.,the first user 102a) and the first access control device 110a (e.g., the vehicle 106) may be greaterthan the threshold distance (e.g., the detection range of the first access control device 110a). Asdescribed in the foregoing description of FIG. 1, to grant the access rights, the key-sharing requestmay be initiated by the first user 102a by way of the service application 116 running on the firstuser device 104a (as shown by arrow 322). For initiating the key-sharing request, the identifier(e.g., a registered phone number, a registered email address, a registered username, or the like) ofthe second user 102b and an access duration for accessing the vehicle 106 may be entered by thefirst user 102a in the service application 116 (as shown by arrow 324). In cases where the first user102a has enrolled assets for the key-sharing service, the first user 102a may also be required toselect an asset for which access rights are granted. In a non-limiting example, only the vehicle 106has been enrolled by the first user 102a for the key-sharing service.Upon initiation of the key-sharing request by the first user 102a, the service application 116 mayprompt the first user 102a to enter the third-party access code (as shown by arrow 326). The thirdpartyaccess code may be entered by the first user 102a in the service application 116 (as shownby arrow 327). The service application 116 may then generate and communicate the key-sharingrequest to the application server 112 (as shown by arrow 328). The key-sharing request mayinclude the identifier of the second user 102b, the access duration, and the third-party access code.Upon receiving the key-sharing request, the application server 112 may validate (e.g., authenticate)the key-sharing request based on the third-party access code included in the key-sharing request(as shown by arrow 330). In other words, the application server 112 may compare the third-partyaccess code included in the key-sharing request with the third-party access code stored in theapplication server 112 (e.g., in the database 214). If the third-party access code included in thekey-sharing request and the third-party access code stored in the application server 112 do notmatch, the application server 112 may communicate a message to the first user device 104a,indicating the third-party access code entered by the first user 102a is invalid. The serviceapplication 116, being executed on the first user device 104a, may prompt the first user 102a to reenterthe third-party access code. In a non-limiting example, the third-party access code includedin the key-sharing request and the third-party access code stored in the application server 112match. Consequently, the application server 112 may communicate a key-sharing response to thefirst user device 104a, indicating that the key-sharing request is approved (as shown by arrow 332).Based on the key-sharing request, the application server 112 may retrieve the vehicle informationof the vehicle 106 and information (e.g., contact details) pertaining to the second user 102b (asshown by arrow 334). The application server 112 may further retrieve, from the database 214, thefirst passcode, the validity period, and the first time-stamp (as shown by arrow 336). In otherwords, the application server 112 may determine, based on information included in the key-sharingrequest, the vehicle 106 that is to be accessed by the second user 102b, the key associated with thevehicle 106, the second user 102b with whom the key is to be shared, and the second user device104b on which the key is to be shared.In a case where the service application 116 does not have the requisite permissions to retrievepasscodes, time-stamps, and / or validity periods stored in the first user device 104a, the serviceapplication 116 may prompt the first user 102a to enter the third-party access code when the firstuser 102a attempts to initiate the key-sharing request. The third-party access code may be validatedby the application server 112, before the service application 116 is allowed to retrieve the firstpasscode, the first time-stamp, and the validity period from the first NFC tag. The key-sharingrequest may be initiated, generated, and communicated only after the entered third-party accesscode is validated by the application server 112. In such a scenario, the key-sharing request mayfurther include the first passcode, the first time-stamp, and the validity period.Referring now to FIG. 3C, the application server 112 may determine, based on the validity periodand the first time-stamp, a remaining validity of the first passcode (as shown by arrow 338). Forexample, if the validity period is "7" hours and the first time-stamp indicates that the first passcodewas synchronized at 4:00 pm on 22nd May 2021, the first passcode may be valid until 11:00 pm on22nd May 2021. If the key-sharing request is received at 5:00 pm, the application server 112 maydetermine that "6" hours are remaining for the first passcode to expire. Further, the applicationserver 112 may compare the access duration (e.g., "25" minutes) with the remaining validity (e.g.,"6" hours) of the first passcode (as shown by arrow 340). If the remaining validity of the firstpasscode is less than the access duration or if a difference between the remaining validity of thefirst passcode and the access duration is less than a pre-determined threshold (e.g., "15" minutes),the application server 112 may deny the key-sharing request and communicate a passcode expirynotification to the first user device 104a. The passcode expiry notification may indicate that thekey-sharing request is denied and that the first passcode is on the verge of expiry. Based on thepasscode expiry notification, the service application 116 may display a message on the displayscreen of the first user device 104a, requesting the first user 102a to re-initiate the key-sharingrequest after a new passcode (e.g., a second passcode) is synchronized between the first user device104a and the first access control device 110a.However, in the current embodiment, the remaining validity of the first passcode (e.g., "6" hours)is greater than the access duration (e.g., "25" minutes). Therefore, the application server 112 maycommunicate, to the second user device 104b, a set of access credentials for enabling the seconduser 102b to access the vehicle 106 (as shown by arrow 342). In a non-limiting example, the setof access credentials may include the first passcode and the access duration. The application server112 may further communicate, to the second user device 104b, the details (e.g., the make andmodel, the color, and / or the registration number) of the vehicle 106 to enable the second user 102bidentify the vehicle 106.The service application 116 on the second user device 104b may store, therein, the set of accesscredentials (as shown by arrow 344). In other words, the service application 116 may write thefirst passcode to the second NFC tag. Further, the service application 116 may display, on thedisplay screen of the second user device 104b, a message indicating that a secondary digital key(e.g., the first passcode) to the vehicle 106 is shared with the second user 102b. The serviceapplication 116 may further display the access duration on the display screen of the second userdevice 104b.The vehicle 106 may be approached by the second user 102b carrying the second user device 104b.When the second user device 104b is within the threshold distance of the first access control device110a, the second user device 104b may communicate or transmit an access request to the firstaccess control device 110a (as shown by arrow 346). In other words, the first access control device110a (e.g., the control circuitry 120) may receive the access request from the second user device104b to establish a connection therewith. The access request may be an RF signal that includes thefirst passcode and the identifier of the second user device 104b. In some cases, the RF signal mayfurther include the access duration.The control circuitry 120 may detect the RF signal being transmitted by the second user device104b (as shown by arrow 348). The first access control device 110a (e.g., the control circuitry 120)may validate the first passcode included in the access request (as shown by arrow 350). In otherwords, the first access control device 110a may compare the first passcode included in the detectedRF signal with the first passcode stored in the control circuitry 120. If the first access control device110a (e.g., the control circuitry 120) determines that the first passcode included in the accessrequest matches the first passcode stored in the control circuitry 120, the control circuitry 120actuates the relay, moving the relay to the "CLOSED" position, thereby switching on the processor118 (as shown by arrow 352).Following the switching on of the processor 118, the control circuitry 120 may communicate anaccess approval message to the second user device 104b (as shown by arrow 354). The accessapproval message may indicate that the second user device 104b has established a connection withthe first access control device 110a and that the second user 102b now has access to the vehicle106. Thus, when the second user 102b is granted the access to the vehicle 106, the first user device104a is beyond the detection range of the first access control device 110a. Further, the accessapproval message may include a second time-stamp indicative of a time-instance (e.g., 5:35 pm,22nd May) at which access to the vehicle 106 was granted to the second user 102b. The serviceapplication 116 may display the access approval message on the display screen of the second userdevice 104b (as shown by arrow 356).Referring now to FIG. 3D, the service application 116 being executed by the second user device104b may communicate the access approval message to the application server 112 (as shown byarrow 358). The application server 112 may store, in the database 214, the second time-stamp (asshown by arrow 360). The application server 112 may also communicate the access approvalmessage to the first user device 104a, notifying the first user 102a that the second user 102b hasgained access to the vehicle 106 (as shown by arrow 362).The processor 118, upon being switched on, may initiate the unlocking of one or more components,such as the doors of the vehicle 106 (as shown by arrow 364). As described in the foregoingdescription of FIG. 2, the processor 118 may initiate the unlocking of the one or more components,using the set of primary digital keys (e.g., the second primary digital key). The second user 102bmay open the now-unlocked doors of the vehicle 106 and enter a cabin of the vehicle 106.In one embodiment, the control circuitry 120 may constantly poll the second user device 104b forthe first passcode. In other words, the control circuitry 120 may at regular intervals of time (e.g.,every minute) request the second user device 104b to present a passcode. If the control circuitry120 determines that the RF signal, being transmitted by the second user device 104b, no longerincludes the first passcode, the control circuitry 120 may communicate a shutdown message to theprocessor 118, indicating that the second user 102b should no longer be provided access to thevehicle 106. In other words, if the second user device 104b fails to respond, to the request fromthe control circuitry 120, with the first passcode, the control circuitry 120 may communicate theshutdown message to the processor 118, indicating that the access of the second user 102b to thevehicle 106 is to be revoked. Based on the received message, the processor 118 may initiate ashutdown procedure.Based on the initiation of the shutdown procedure, the processor 118 may control the set of motorsto close / lock the doors of the vehicle 106, close / lock the boot lid of the vehicle 106, close / lock thecharging port lid of the vehicle 106, or the like. Further, the processor 118 may initiate a shuttingdown of one or more accessories (e.g., the touchscreen console, the multi-information display, themusic system, or the like) in the vehicle 106, as part of the shutdown procedure. In other words,based on the initiation of the shutdown procedure, the processor 118 may initiate a locking ofvarious components in the vehicle 106. In one embodiment, prior to the initiation of the shut-downprocedure, the processor 118 (e.g., the first access control device 110a) may provide visual oraudio cues to the second user 102b to exit the vehicle 106. For example, the processor 118 may beconfigured to display a "Please exit the vehicle" or "Access is revoked" message on a display ofthe touchscreen console of the vehicle 106. Similarly, the processor 118 may be configured to playa "Please exit the vehicle" or "Access is revoked" message through one or more speakers in thevehicle 106.However, for the sake of brevity, it is assumed that the RF signal transmitted by the first signalcontinues to include the first passcode while the second user 102b is in the cabin of the vehicle106. The item may be retrieved from the vehicle 106 by the second user 102b. Further, the doorsof the vehicle 106 may be shut by the second user 102b upon exiting the cabin of the vehicle 106.The second user 102b may then walk away.When the second user device 104b is beyond the threshold distance of the first access controldevice 110a, the control circuitry 120 may fail to detect any signal (e.g., RF signal) from the seconduser device 104b, and may request the processor 118 to initiate the shutdown procedure. Theprocessor 118 may initiate the shutdown procedure to lock the vehicle 106 (as shown by arrow366). Following the completion of the shutdown procedure, the control circuitry 120 may actuatethe relay, moving the relay back to the "OPEN" position and switching off (e.g., deactivating) theprocessor 118 (as shown by arrow 368). Alternatively, the control circuitry 120 may communicatethe shutdown message to the processor 118 based on the lapse of the access duration. The operationof the processor 118 in such a scenario remains the same as described above.When the service application 116 determines that the second user device 104b is no longerconnected to the control circuitry 120, the service application 116 may communicate a vehicle exitnotification to the application server 112, indicating that the second user 102b has exited thevehicle 106 (as shown by arrow 370). The vehicle exit notification may include a third time-stampthat is indicative of a time-instance (e.g., 5:40 pm, 22nd may) at which the second user 102b exitedthe vehicle 106. The application server 112 may store, in the database 214, the third time-stamp(as shown by arrow 372). The application server 112 may communicate the vehicle exitnotification to the first user device 104a, notifying the first user 102a of the exit of the second user102b from the vehicle 106 (as shown by arrow 374).Referring now to FIG. 3E, based on the received vehicle exit notification, the application server112 may communicate the access credentials deletion request to the service application 116 beingexecuted on the second user device 104b (as shown by arrow 376). The access credentials deletionrequest may be a request for deletion of the set of access credentials communicated by theapplication server 112 to the second user device 104b. Based on the access credentials deletionrequest, the service application 116 may delete the set of access credentials from the second userdevice 104b, revoking access rights of the second user 102b to the vehicle 106 (as shown by arrow378). The service application 116 may delete the first passcode stored in the second NFC tag. Theservice application 116 may further delete the access duration and the details of the vehicle 106from the second user device 104b.Following the deletion of the set of access credentials, the service application 116 maycommunicate an access credentials deletion response to the application server 112 (as shown byarrow 380). The access credentials deletion response may indicate that the set of access credentialshas been deleted from the second user device 104b. The application server 112 may communicatethe access credentials deletion response to the first user device 104a, notifying the first user 102aof the revocation of the access rights of the second user 102b to the vehicle 106 (as shown byarrow 382). The first access control device 110a may update the first passcode when the validityperiod elapses (as shown by arrow 384). In other words, the first access control device 110a maygenerate a second passcode when the first passcode expires. The second passcode may besynchronized with the first user device 104a when the first user device 104a is within the thresholddistance of the first access control device 110a.In FIGS. 3A-3E, it is assumed that passcodes are generated by the first access control device 110a.However, in another embodiment, passcodes for the vehicle 106 may be generated by the first userdevice 104a. In such scenarios, upon generation of a passcode, the first user device 104a maycommunicate the passcode to the first access control device 110a when the first user device 104ais within the threshold distance of the first access control device 110a. In other words, the firstaccess control device 110a may receive the passcode from the first user device 104a when the firstuser device 104a is within the threshold distance of the first access control device 110a. The firstaccess control device 110a may store, therein, the passcode received from the first user device104a. The passcode may thus be synchronized between the first access control device 110a andthe first user device 104a. The service application 116 that is being executed on the first user device104a may further communicate the generated passcode to the application server 112 in a similarmanner as described above.In yet another embodiment, passcodes for the vehicle 106 may be generated by the applicationserver 112. In such a scenario, the application server 112 may communicate the generated passcodeto the first user device 104a, which, in turn, synchronizes the passcode with the first access controldevice 110a. In other words, the first access control device 110a may receive the passcode fromthe first user device 104a when the first user device 104a is within the threshold distance of thefirst access control device 110a to synchronize the passcode therewith. The remaining process forkey-sharing, granting of access rights, and revocation of access rights may be the same as describedin FIGS. 3A-3E.In FIGS. 1 and 3A-3E, there is no direct communication between the application server 112 andthe first access control device 110a / the second access control device 110b. However, in anotherembodiment, the application server 112 may be configured to directly communicate with the firstand second access control devices 110a and 110b. In such scenarios, any passcode generated and / orstored in the first access control device 110a and / or the second access control device 110b may bedirectly synchronized with the application server 112.In FIGS. 3A-3E, the first passcode to the vehicle 106 is shared with a single user (e.g., the seconduser 102b). However, it will be apparent to those of skill in the art that the first passcode (e.g.,access rights) may be shared with multiple users simultaneously without deviating from the scopeof the disclosure.In another embodiment, the service application 116 may be used by the first user 102a to raise aservice request, for example, for cleaning the vehicle 106, for re-fueling the vehicle 106, forchanging a flat tire of the vehicle 106, for charging a battery of the vehicle 106, or the like. In sucha scenario, an intended recipient of the first passcode may not be specified by the first user 102a.The application server 112 may, based on the raised service request, select a service-provider (e.g.,a car-cleaning service, a tire-replacement service, or the like) for addressing the service request.The selected service-provider (e.g., the selected second user 102b) may be registered with theapplication server 112 for the key-sharing service. The application server 112 may then presentthe selected service-provider to the first user 102a on the first user device 104a. The selectedservice-provider may then be approved by the first user 102a. In such a scenario, the applicationserver 112 may receive a user approval message from the first user device 104a indicating that theselected service-provider is approved for the access to the vehicle 106. Further, the applicationserver 112 may determine (e.g., identify) the user device associated with the selected serviceproviderfor communicating the set of access credentials. The service-provider may access thevehicle 106, using the set of access credentials, and service the vehicle 106 as per the servicerequest. Later, the set of access credentials may be deleted from the user device of the serviceprovider(as described in the foregoing description of FIG. 3E).In another embodiment, a time-window (e.g., 5:15 pm - 6:00 pm) may be specified by the firstuser 102a, in addition to the access duration, when initiating the key-sharing request. In otherwords, the key-sharing request further indicates the time-window during which the access to thevehicle 106 is to be granted to the second user 102b. In such a scenario, the vehicle 106 may beaccessed by the second user 102b only within the specified time-window. Thus, the applicationserver 112 communicates the set of access credentials (e.g., the first passcode) to the second userdevice 104b at a start of the time-window.In another embodiment, the key-sharing request may indicate that the second user 102b is to begranted periodic access (e.g., recurring access) to the vehicle 106. For example, the key-sharingrequest may indicate that the second user 102b is to be granted access rights to the vehicle 106every Monday within a specified time-window (e.g., 5:15 pm - 6:00 pm). In such a scenario, thevehicle 106 may be accessed by the second user 102b every Monday within the specified time-window. The first passcode may be shared with the second user device 104b every Monday at thestart of the specified time-window. The access rights granted to the second user 102b may berevoked by the first user 102a at any time-instance.In another embodiment, the access duration may elapse before the second user 102b exits thevehicle 106. In such a scenario, the service application 116, being executed on the second userdevice 104b, may delete the set of access credentials from the second user device 104b. In such ascenario, the RF signal transmitted by the second user device 104b may no longer include the firstpasscode, prompting the processor 118 to initiate the shutdown procedure.In another embodiment, the access is granted to the second user 102b in such a manner that thevehicle 106 may be accessed by the second user 102b multiple times during the access duration.For example, if the second user device 104b moves beyond the detection range of the first accesscontrol device 110a accidentally or after successfully completing the access, and the accessduration has not lapsed, the set of access credentials is not deleted from the second user device104b. Thus, the vehicle 106 may be accessed again by the second user 102b once the second userdevice 104b is within the detection range of the first access control device 110a. In such cases, theset of access credentials is deleted from the second user device 104b exclusively on the lapse ofthe access duration. However, each time the second user device 104b moves beyond the detectionrange of the first access control device 110a, the control circuitry 120 may request the processor118 to initiate the shutdown procedure.In another embodiment, the previously-granted access rights of the second user 102b to the vehicle106 may be revoked by the first user 102a. In such a scenario, an access revocation request maybe initiated by the first user 102a by way of the service application 116 being executed on the firstuser device 104a. The access revocation request may indicate that access granted to the seconduser 102b is to be revoked. The service application 116 on the first user device 104a maycommunicate the access revocation request to the application server 112. The access revocationrequest may be initiated and communicated to the application server 112, before the vehicle 106is accessed by the second user 102b or while the vehicle 106 is being accessed by the second user102b. Based on the access revocation request, the application server 112 may communicate theaccess credentials deletion request to the service application 116 being executed on the seconduser device 104b. Based on the access credentials deletion request, the service application 116 maydelete the set of access credentials from the second user device 104b, revoking access rights of thesecond user 102b to the vehicle 106. The service application 116 may display, on the display screenof the second user device 104b, a message indicating that the access of the second user 102b hasbeen revoked by the first user 102a. Consequently, the service application 116 may communicatethe access credentials deletion response to the application server 112. The application server 112may communicate the access credentials deletion response to the first user device 104a, notifyingthe first user 102a of the revocation of the access rights of the second user 102b.In another embodiment, the access duration may not be sufficient for the second user 102b tocomplete the task for which the second user 102b is granted access to the vehicle 106. In such ascenario, an extension of the access duration may be requested by the second user 102b, by wayof the second user device 104b. In other words, the second user device 104b may generate anextension request to extend the access duration. The extension request may include an extensionduration indicative of the extended time-period for which the vehicle 106 is to remain accessibleto the second user 102b. For example, if the access duration is equal to "15" minutes, additional"10" minutes may be requested by the second user 102b to complete the task for which the seconduser 102b is granted the access. The application server 112 may be configured to receive theextension request from the second user device 104b and present the extension request to the firstuser 102a by way of the first user device 104a. The extension request may be approved or rejectedby the first user 102a. For the sake of ongoing discussion, it is assumed that the extension requestis approved by the first user 102a. In such a scenario, the application server 112 is furtherconfigured to receive an extension approval message from the first user device 104a in responseto the extension request. The access duration is updated based on the extension duration. Thus, thefirst access control device 110a grants the second user 102b the access to the vehicle 106 for theupdated access duration.In another embodiment, the extension request may not include the extension duration. In such ascenario, the extension duration may be defined by the first user 102a by way of the first userdevice 104a while approving the extension request. In other words, the extension approval messageincludes the extension duration.In a current embodiment, it is assumed that the access rights provided to the second user 102b maybe absolute (e.g., the second user 102b is granted access to the vehicle 106 in entirety). In otherwords, when in possession of the first passcode, the second user 102b may, throughout the accessthe duration, have the same level of access to the vehicle 106 as the first user 102a. For example,the second user 102b may open doors of the vehicle 106, open the boot lid of the vehicle 106, openthe lid of the charging port in the vehicle 106, make positional adjustments to electrically-poweredseats in the vehicle 106, drive the vehicle 106, or the like.However, in another embodiment, the vehicle 106 may be divided into multiple parts (e.g., theplurality of vehicular systems) and the first access control device 110a may generate multiplepasscodes (e.g., secondary digital keys) that control access to the parts of the vehicle 106,respectively. In other words, each of the multiple passcodes is mapped to or associated with aunique set of access rights or access privileges. For example, one passcode may be a masterpasscode that allows a user to access all functionalities or components of the vehicle 106. Anotherpasscode may be associated with a privilege to only open the boot lid of the vehicle 106. Anotherpasscode may be associated with a privilege to open the boot lid and the doors of the vehicle 106.Another passcode may be associated with a privilege to open the boot lid of the vehicle 106, openthe doors of the vehicle 106, and use the music system in the vehicle 106. Each of these passcodesmay be synchronized between the first access control device 110a and the first user device 104a.In such a scenario, during the initiation of the key-sharing request, a level of access to be providedto the second user 102b may be specified by the first user 102a. The key-sharing request mayfurther include an access level indicating that the second user 102b is to be granted access to aspecific part of the vehicle 106. Consequently, the application server 112 may select an appropriatepasscode, from the multiple passcodes, to be communicated to the second user device 104b basedon the access level. The vehicle 106 may be accessed by the second user 102b based on thepasscode received from the application server 112. However, one or more functions in the vehicle106 may be restricted to the second user 102b, based on the set of access rights or privilegesassociated with the passcode. For example, if the passcode communicated to the second user 102bis only associated with the right to open the boot lid of the vehicle 106, the doors of the vehicle106 may not be unlocked for the second user 102b.In another embodiment, access to the vehicle 106 may require an additional level of authentication(e.g., two-factor authentication). For example, the application server 112 may store therein userauthentication data of a set of users (e.g., the first and second users 102a and 102b). In a nonlimitingexample, the user authentication data may include biometric data such as, but not limitedto, face data of the set of users, fingerprint data of the set of users, iris data of the set of users, orthe like. It will be apparent to those of skill in the art that the user authentication data is not limitedto biometric data. The user authentication data may also include passwords or any other data thatuniquely identifies a user (e.g., the second user 102b) such as, but not limited to, a driving licensenumber of the user, a social security number of the user, or the like. Before the set of accesscredentials is communicated to a user device (e.g., the second user device 104b) of a user (e.g., thesecond user 102b), the application server 112 may communicate a user authentication request tothe user device for obtaining user authentication data of the user.Based on the received user authentication request, the service application 116 that is beingexecuted on the user device (e.g., the second user device 104b) may prompt the user to entercorresponding user authentication data. In a non-limiting example, the service application 116 mayprompt the user to direct the user device (e.g., a front camera of the user device) towards his faceto enable the user device to capture an image of his face. The user device (e.g., the second userdevice 104b) may extract, from the captured image, face data of the face of the user. The userdevice may communicate, to the application server 112, a response to the received userauthentication request. The response may include user authentication data (e.g., the extracted facedata) of the user. The application server 112 may validate the user authentication data included inthe response to authenticate the second user 102b. In other words, the application server 112 maycompare the user authentication data, included in the received response, with the userauthentication data of the user that is stored in the application server 112. Based on a successfulvalidation of the user authentication data, the application server 112 may communicate the set ofaccess credentials to the user device (e.g., the second user device 104b). However, if the validationof the user authentication data is unsuccessful, the application server 112 may not communicatethe set of access credentials to the user device.Alternatively, the application server 112 may communicate the set of access credentials to the userdevice (e.g., the second user device 104b) before the user (e.g., the second user 102b) is prompted,by the service application 116, to provide the user authentication data. The user authentication datamay be validated by the application server 112 and / or the service application 116 being executedon the user device (e.g., the second user device 104b). Based on a successful validation of the userauthentication data provided by the user, the user device may communicate the access request tothe first access control device 110a (e.g., the first access control device 110a receives the accessrequest from the user device). If the validation of the user authentication data provided by the useris unsuccessful, the user device may not communicate the access request to the first access controldevice 110a.In another embodiment, the first access control device 110a (e.g., the control circuitry 120) maystore therein the user authentication data of the set of users (e.g., the first and second users 102aand 102b). The first access control device 110a may receive user authentication data from the user(e.g., the second user 102b) when the user attempts to access the vehicle 106. The first accesscontrol device 110a may include a set of sensors (e.g., fingerprint sensors, image sensors, or thelike) for receiving user authentication data from the user. The first access control device 110a mayvalidate the received user authentication data to authenticate the user (e.g., the second user 102b).If both the first passcode, included in the access request, and the received user authentication dataare successfully validated, the control circuitry 120 may actuate the relay, powering on theprocessor 118. The processor 118 may provide the user access to the vehicle 106. The validationof the user authentication data may be performed before or after the validation of the first passcodeincluded in the access request. If validation of one of the user authentication data of the user andthe first passcode is unsuccessful, the user (e.g., the second user 102b) is denied access to thevehicle 106.In another embodiment, the first access control device 110a may not include the set of sensors. Insuch a scenario, a user device (e.g., the second user device 104b) of the user (e.g., the second user102b) may include the set of sensors. The user device may receive user authentication data (e.g.,the biometric data) of the user. In such a scenario, the access request communicated, by the userdevice (e.g., the second user device 104b) to the first access control device 110a, may include thereceived user authentication data. Further, the synchronization of new passcodes between the firstaccess control device 110a and the first user device 104a may be based on the validation of userauthentication data of the first user 102a.FIGS. 4A-4C, are diagrams, which collectively, represents an exemplary scenario 400 thatillustrates user interface (UI) screens 402-422 rendered on the first user device 104a for facilitatingthe cloud-based sharing of the digital keys, in accordance with an exemplary embodiment of thepresent disclosure. FIGS. 4A-4C are explained in conjunction with FIGS. 1 and 3A-3E. The UIscreens 402-422 are displayed on the display screen of the first user device 104a by the serviceapplication 116.Referring to FIG. 4A, when the service application 116 on the first user device 104a is accessedby the first user 102a, the service application 116 may render the UI screen 402. The UI screen402 may request the first user 102a to enter a username and a password to log into the serviceapplication 116. The first user 102a may enter his username and password (e.g., the logincredentials of the first user 102a) in first and second text boxes 424 and 426, respectively. Afterentering the username (e.g., "John Doe") and the password (e.g., "********"), a first submitbutton 428 may be selected by the first user 102a for logging into the service application 116. Thefirst user device 104a may communicate an authentication request to the application server 112 forauthentication of the first user 102a. The authentication request may include the username and thepassword entered by the first user 102a.The application server 112 may authenticate the first user 102a, by comparing the username andpassword, included in the authentication request, with the username and password stored in thedatabase 214 (e.g., the username and password created at the time of registration). In a non-limitingexample, it is assumed the first user 102a is successfully authenticated. Based on theauthentication, the application server 112 may communicate an authentication response to the firstuser device 104a. The authentication response is indicative of the successful authentication of thefirst user 102a. Control is then redirected to the UI screen 404.The UI screen 404 displays a message (e.g., "Login successful") indicating that the first user 102ahas successfully logged into the service application 116. The service application 116 maycommunicate the first passcode, the first time-stamp, and the validity period to the applicationserver 112. In other words, the service application 116 may facilitate synchronization, of thesecondary digital key (e.g., the first passcode) of the vehicle 106, between the first user device104a and the application server 112. Based on the communication of the first passcode, the firsttime-stamp, and the validity period, UI screen 404 displays another message (e.g., "Synchronizingdigital key for vehicle") indicating that the first passcode for the vehicle 106 is being synchronized.Following the synchronization of the secondary digital key, control is redirected to the UI screen406.The UI screen 406 displays a message (e.g., "Digital key successfully synchronized), indicatingthat the secondary digital key (e.g., the first passcode) has been synchronized between the firstuser device 104a and the application server 112. Control is then redirected to the UI screen 408.The UI screen 408 displays a first user-selectable option 430 (e.g., "Share key") for selection. Thefirst user-selectable option 430 allows the first user 102a to initiate a request (e.g., the key-sharingrequest) for sharing the secondary digital key to the vehicle 106 with another user (e.g., the seconduser 102b). Based on the selection of the first user-selectable option 430 by the first user 102a,control is redirected to the UI screen 410.Referring to FIG. 4B, the UI screen 410 requests the first user 102a to enter an identifier (e.g.,username) of a user (e.g., recipient) with whom the secondary digital key to the vehicle 106 is tobe shared. The UI screen 410 also prompts the first user 102a to set the access duration for therecipient. The first user 102a enters the username (e.g., "Simon Smith") of the second user 102band the access duration (e.g., "25" minutes), in third and fourth text boxes 432 and 434,respectively. After entering the username of the second user 102b and the access duration, a secondsubmit button 436 initiating the key-sharing request is selected by the first user 102a. When thekey-sharing request is initiated, control is redirected to the UI screen 412.The UI screen 412 displays a message, requesting the first user 102a to enter the third-party accesscode. The third-party access code may be entered by the first user 102a in a fifth text box 438.After entering the third-party access code (e.g., "****"), a third submit button 440 for generatingthe key-sharing request may be selected by the first user 102a. The service application 116generates and communicates the key-sharing request to the application server 112. Based on thekey-sharing request, the application server 112 communicates the key-sharing response to the firstuser device 104a. If the key-sharing response indicates that the key-sharing request is approved,control is redirected to the UI screen 414.The UI screen 414 displays a message, indicating that the key-sharing request is approved and thataccess credentials for accessing the vehicle 106 would be provided to the second user 102b (e.g.,"Simon Smith"). When the application server 112 notifies the service application 116 on the firstuser device 104a that the first passcode and the access duration have been communicated to thesecond user device 104b, control is redirected to the UI screen 416.The UI screen 416 displays a message, indicating that the access credentials for accessing thevehicle 106 have been shared with Simon Smith. The UI screen 416 further displays a second user-selectable option 442 (e.g., "Revoke Access") that enables the first user 102a to initiate the accessrevocation request. If the second user-selectable option 442 is selected by the first user 102a, theservice application 116 may communicate the access revocation request to the application server112. However, in the current embodiment, the second user-selectable option 442 is not selected bythe first user 102a. When the first user device 104a receives the access approval message from theapplication server 112, control is redirected to the UI screen 418.Referring to FIG. 4C, the UI screen 418 displays a message indicating that the second user 102bhas successfully gained access to the vehicle 106. The UI screen 418 further displays the seconduser-selectable option 442 (e.g., "Revoke Access"). In the current embodiment, the second userselectableoption 442 is not selected by the first user 102a. When the first user device 104a receivesthe vehicle exit notification from the application server 112, the UI screen 420 is rendered.The UI screen 420 displays a message, indicating that the second user 102b has exited the vehicle106. When the first user device 104a receives the access credentials deletion response from theapplication server 112, control is redirected to the UI screen 422.The UI screen 422 displays a message, indicating that the set of access credentials that was sharedwith the second user 102b has been deleted from the second user device 104b (e.g., access rightsof the second user 102b have been revoked).FIG. 5 is a flow chart 500 that illustrates the method for facilitating key-sharing between the firstand second user devices 104a and 104b, in accordance with an exemplary embodiment of thepresent disclosure. FIG. 5 is explained in conjunction with FIGS. 3A-3E.At 502, the first passcode is generated. The first passcode may be generated by the first accesscontrol device 110a, the first user device 104a, or the application server 112. At 504, the firstpasscode is synchronized. The first passcode may be synchronized between the first access controldevice 110a and the first user device 104a (as described in the foregoing description of FIGS. 1and 3A). At 506, the key-sharing request is generated. The key-sharing request is generated at thefirst user device 104a, by the first user 102a, for sharing the first passcode with the second user102b. The key-sharing request, as described in the foregoing description of FIG. 3B, includes theaccess duration and the identifier of the second user 102b. At 508, the set of access credentials iscommunicated to the second user device 104b. The application server 112 communicates the setof access credentials to the second user device 104b, based on the received key-sharing request.After receiving the set of access credentials, the second user 102b, with the second user device104b, approaches the vehicle 106. When the second user device 104b is within the thresholddistance of the first access control device 110a, a connection between the second user device 104band the control circuitry 120 is established. The second user device 104b provides the firstpasscode to the control circuitry 120. In other words, the second user device 104b communicatesthe access request to the control circuitry 120.At 510, the processor 118 is switched on when the access request is received from the second userdevice 104b. The control circuitry 120 actuates the relay when the access request is received fromthe second user device 104b, moving the relay to the "CLOSED" position and switching on (e.g.,powering on) the processor 118. At 512, the unlocking of the vehicle 106 is initiated. The processor118 initiates the unlocking of the vehicle 106, as described in the foregoing description of FIG.3D. The control circuitry 120 communicates the access approval message to the second user device104b. Based on the access approval message, the second user 102b accesses (e.g., enters) thevehicle 106 and retrieves the item from the cabin of the vehicle 106. Consequently, the seconduser 102b exits the vehicle 106, closes the doors of the vehicle 106, and walks away. When thesecond user device 104b is beyond the threshold distance of the first access control device 110a,the second user device 104b is no longer connected to the first access control device 110a (e.g.,the control circuitry 120). In other words, the control circuitry 120 does not detect the RF signalfrom the second user device 104b. The control circuitry 120 prompts or requests the processor 118to initiate locking of the vehicle 106 (e.g., initiate the shutdown procedure). At 514, the locking ofthe vehicle 106 is initiated. The processor 118 initiates the locking of the vehicle 106 by initiatingthe shutdown procedure. Upon completion of the shutdown procedure, the control circuitry 120actuates the relay, moving the relay to the "OPEN" position and, thereby, switching off theprocessor 118.The service application 116 on the second user device 104b communicates the vehicle exitnotification to the application server 112. At 516, the access rights of the second user 102b arerevoked. The application server 112 revokes the access rights of the second user 102b to the vehicle106, based on the vehicle exit notification. For revoking the access rights of the second user 102b,the application server 112 communicates the access credentials deletion request to the second userdevice 104b. The service application 116, on the second user device 104b, deletes the set of accesscredentials from the second user device 104b, based on the access credentials deletion request. Theservice application 116, then, communicates the access credentials deletion response to theapplication server 112. The application server 112 communicates the access credentials deletionresponse to the first user device 104a.Various embodiments of the disclosure provide an access management system that includes theapplication server 112 and the first access control device 110a that controls the access to the vehicle106. The application server 112 may be configured to receive, from the first user device 104a ofthe first user 102a, the key-sharing request to grant the second user 102b, that is different from thefirst user 102a, the access to the vehicle 106 associated with the first user 102a. The key-sharingrequest includes the access duration that is indicative of the time-period for which the vehicle 106is to remain accessible to the second user 102b. The application server 112 may be furtherconfigured to determine, based on the key-sharing request, the digital key associated with thevehicle 106, and communicate, based on the identifier of the second user 102b, the digital key tothe second user device 104b of the second user 102b. Based on the second user device 104b beingwithin the detection range of the first access control device 110a, the first access control device110a may be configured to receive the digital key from the second user device 104b and validatethe digital key. The first access control device 110a may be further configured to grant, based onthe validation of the digital key, the second user 102b the access to the vehicle 106 for the accessduration.The disclosed methods encompass numerous advantages. The disclosed methods describe sharing,among users, of secondary digitals keys to access assets such as vehicles (e.g., the vehicle 106),facilities (e.g., the facility 108), safe lockers, or the like. The key-sharing enables a user to share akey to an asset with another user, even when the user (e.g., the first user 102a) is at a remotelocation away from the asset and the other user (e.g., the second user 102b). This provides a highlevel of convenience to a user who may wish to provide another user temporary access to his orher asset. Any digital key (e.g., the first passcode) that is shared between user devices (e.g., thefirst and second user devices 104a and 104b) is a secondary digital key that is periodically updatedor changed. The secondary digital key expires when a validity period associated with the secondarydigital key elapses. Thus, the asset is accessible to the other user (e.g., the second user 102b) byway of the associated user device (e.g., the second user device 104b) exclusively for a limitedperiod of time. Further, any primary digital keys (e.g., the set of primary digital keys) associatedwith the asset (e.g., the vehicle 106) are not shared. This limits a risk of sharing keys with otherusers. The disclosed methods enable a user to set an access duration (e.g., "25" minutes) and alevel of access privilege when sharing a key with another user, thereby further reducing the risk ofsharing keys. Access credentials (e.g., the set of access credentials) that are shared with a recipient(e.g., the second user 102b) may be deleted when the recipient exits the asset, when an accessduration set for the recipient lapses, or when a user or owner of the asset raises an access revocationrequest. Therefore, a comprehensive hardware and software solution is provided for enabling risk-freesharing of digital keys.Techniques consistent with the disclosure provide, among other features, systems and methods forfacilitating key-sharing between user devices. While various exemplary embodiments of thedisclosed systems and methods have been described above, it should be understood that they havebeen presented for purposes of example only, and not limitations. It is not exhaustive and does notlimit the disclosure to the precise form disclosed. Modifications and variations are possible in lightof the above teachings or may be acquired from practicing the disclosure, without departing fromthe breadth or scope.While various embodiments of the disclosure have been illustrated and described, it will be clearthat the disclosure is not limited to these embodiments only. Numerous modifications, changes,variations, substitutions, and equivalents will be apparent to those skilled in the art, withoutdeparting from the spirit and scope of the disclosure, as described in the claims.

Claims

1. An access management system, comprising: a server (112) configured to receive, from a first user device (104a) of a first user (102a), a key-sharing request to grant a second user (102b), that is different from the first user (102a), an access to an asset (106, 108) associated with the first user (102a), wherein the key-sharing request comprises an access duration that is indicative of a time-period for which the asset (106, 108) is to remain accessible to the second user (102b), and wherein based on the key-sharing request, the server (112) is further configured to determine a digital key associated with the asset (106, 108) and communicate, over a communication network (114), the digital key to a second user device (104b) of the second user (102b); and an access control device (110a, 110b) configured to control the access to the asset (106, 108), wherein based on the second user device (104b) being within a detection range of the access control device (110a, 110b), the access control device (110a, 110b) is further configured to receive the digital key from the second user device (104b), validate the digital key, and grant, based on the validation of the digital key, the second user (102b) the access to the asset (106, 108) for the access duration.

2. The access management system as claimed in claim 1, wherein the access control device (110a, 110b) comprises: a processor (118) configured to control the access to the asset (106, 108), wherein the asset (106, 108) is inaccessible when the processor (118) is deactivated; a power source (122); and control circuitry (120) coupled to the processor (118) and the power source (122), wherein the control circuitry (120) is configured to: receive the digital key from the second user device (104b); validate the digital key; and activate the processor (118) based on the validation of the digital key, wherein the control circuitry (120) activates the processor (118) by coupling the processor (118) to the power source (122), wherein based on the activation, the processor (118) is further configured to grant the second user (102b) the access to the asset (106, 108), and wherein the access to the asset (106, 108) corresponds to unlocking the asset (106, 108).

3. The access management system as claimed in claim 2, wherein based on the granted access, the control circuitry (120) is further configured to periodically poll the second user device (104b) for the digital key, wherein based on a halt in the reception of the digital key from the second user device (104b), the control circuitry (120) is further configured to communicate a shutdown message to the processor (118), and wherein the processor (118) is further configured to initiate, based on the shutdown message, a shutdown procedure to lock the asset (106, 108).

4. The access management system as claimed in claim 3, wherein the control circuitry (120) is further configured to deactivate the processor (118) based on completion of the shutdown procedure, and wherein the control circuitry (120) deactivates the processor (118) by decoupling the processor (118) from the power source (122).

5. The access management system as claimed in claim 2, wherein the asset (106, 108) comprises one or more components, wherein the processor (118) is configured to control functioning of the one or more components of the asset (106, 108) to control the access to the asset (106, 108), and wherein the processor (118) controls the functioning of the one or more components by way of a set of digital keys that is different from the digital key received from the second user device (104b).

6. The access management system as claimed in claim 1, wherein the key-sharing request comprises an access code associated with the first user (102a), wherein the server (112) is further configured to validate the key-sharing request based on the access code, and wherein the server (112) communicates the digital key to the second user device (104b) based on the validation of the key-sharing request.

7. The access management system as claimed in claim 1, wherein the key-sharing request further indicates a time-window during which the access to the asset (106, 108) is to be granted to the second user (102b), and wherein the server (112) communicates the digital key to the second user device (104b) at a start of the time-window.

8. The access management system as claimed in claim 1, wherein the server (112) is further configured to communicate an access credentials deletion request to the second user device (104b), wherein the server (112) communicates the access credentials deletion request based on (i) a lapse of the access duration, (ii) an access revocation request generated by the first user device (104a) to indicate that the access granted to the second user (102b) is to be revoked, or (iii) a notification generated by the second user device (104b) to indicate that the asset (106, 108) is successfully accessed by the second user (102b) and a distance between the second user device (104b) and the access control device (110a, 110b) is greater than the detection range after successfully accessing the asset (106, 108), and wherein based on the access credentials deletion request, the digital key is deleted from the second user device (104b), thereby revoking the access of the second user (102b) to the asset (106, 108).

9. The access management system as claimed in claim 1, wherein the server (112) is further configured to: receive, from the second user device (104b), an extension request to extend the access duration; present the extension request to the first user (102a) by way of the first user device (104a); and receive, from the first user device (104a) in response to the extension request, an extension approval message indicating that the extension request is approved, wherein the access duration is updated based on an extension duration indicative of an extended time-period for which the asset (106, 108) is to remain accessible to the second user (102b), wherein the extension request or the extension approval message comprises the extension duration, and wherein the access control device (110a, 110b) grants the second user (102b) the access to the asset (106, 108) for the updated access duration.

10. The access management system as claimed in claim 1, wherein when the access to the asset (106, 108) is granted to the second user (102b), the first user device (104a) is beyond the detection range of the access control device (110a, 110b).

11. The access management system as claimed in claim 1, wherein based on the digital key, the second user (102b) is granted access to the asset (106, 108) in entirety.

12. The access management system as claimed in claim 1, wherein the asset (106, 108) is divided into a plurality of parts, wherein an access to the plurality of parts is controlled by way of a plurality of digital keys, respectively, wherein the key-sharing request comprises an access level indicating that the second user (102b) is to be granted access to a first part of the asset (106, 108), and wherein the server (112) is further configured to select, from the plurality of digital keys based on the access level, the digital key that is associated with the first part of the asset (106, 108).

13. The access management system as claimed in claim 1, wherein the server (112) is further configured to: communicate a user authentication request to the second user device (104b); receive, as a response to the user authentication request, user authentication data associated with the second user (102b); and validate the user authentication data to authenticate the second user (102b), wherein based on the validation of the user authentication data, the server (112) communicates the digital key to the second user device (104b) or the access control device (110a, 110b) receives the digital key from the second user device (104b).

14. The access management system as claimed in claim 1, wherein the access control device (110a, 110b) is further configured to: receive, based on an attempt of the second user (102b) to access the asset (106, 108), user authentication data associated with the second user (102b); and validate the user authentication data to authenticate the second user (102b), wherein the access control device (110a, 110b) grants the second user (102b) the access to the asset (106, 108) based on the validation of the user authentication data.

15. The access management system as claimed in claim 1, wherein, prior to the server (112) receiving the key-sharing request from the first user device (104a), the digital key is synchronized between the first user device (104a) and the access control device (110a, 110b) based on the first user device (104a) being within the detection range of the access control device (110a, 110b), wherein the server (112) is further configured to receive, from the first user device (104a), a first time-stamp indicative of a time-instance at which the digital key is synchronized between the first user device (104a) and the access control device (110a, 110b) and a validity period of the digital key, wherein when the key-sharing request is received, the server (112) is further configured to determine, based on the validity period and the first time-stamp, a remaining validity of the digital key and compare the access duration with the remaining validity of the digital key, and wherein the server (112) communicates the digital key to the second user device (104b) based on the remaining validity of the digital key being greater than the access duration by a pre- determined threshold.

16. The access management system as claimed in claim 1, wherein the access control device (110a, 110b) is further configured to generate the digital key and synchronize the digital key with the first user device (104a) based on the first user device (104a) being within the detection range of the access control device (110a, 110b), wherein the digital key is synchronized between the first user device (104a) and the access control device (110a, 110b) prior to the server (112) receiving the key-sharing request from the first user device (104a), and wherein the server (112) is further configured to receive the digital key from the first user device (104a) as a part of the key-sharing request or when the digital key is synchronized.

17. The access management system as claimed in claim 1, wherein the digital key is generated by the first user device (104a), wherein the access control device (110a, 110b) is further configured to receive, based on the first user device (104a) being within the detection range of the access control device (110a, 110b), the digital key from the first user device (104a) to synchronize the digital key therebetween, wherein the digital key is synchronized between the first user device (104a) and the access control device (110a, 110b) prior to the server (112) receiving the key-sharing request from the first user device (104a), and wherein the server (112) is further configured to receive the digital key from the first user device (104a) as a part of the key-sharing request or when the digital key is generated by the first user device (104a).

18. The access management system as claimed in claim 1, wherein the server (112) is further configured to generate the digital key and communicate the digital key to the first user device (104a), wherein the access control device (110a, 110b) is further configured to receive, based on the first user device (104a) being within the detection range of the access control device (110a, 110b), the digital key from the first user device (104a) to synchronize the digital key therebetween, and wherein the digital key is synchronized between the first user device (104a) and the access control device (110a, 110b) prior to the server (112) receiving the key-sharing request from the first user device (104a).

19. The access management system as claimed in claim 1, wherein the key-sharing request comprises an identifier of the second user (102b), and wherein the server (112) is further configured to determine, based on the key-sharing request, the second user (102b) to whom the access is to be granted and the second user device (104b) associated with the second user (102b).

20. The access management system as claimed in claim 1, wherein the server (112) is further configured to: select, based on the key-sharing request, the second user (102b); present the selected second user (102b) to the first user (102a) by way of the first user device (104a); receive a user approval message from the first user device (104a) indicating that the second user (102b) is approved for the access to the asset (106, 108); and determine the second user device (104b) associated with the second user (102b) for communicating the digital key.