Granting permissions and access to devices and third parties

Abstract

Aspects of the present disclosure include a method for delegating authorization to create a token from an owner of an ownership to a sharing platform that manages a subscription for the ownership. A method can include receiving a request to delegate authorization for generating a token for one or more accessory devices, the delegate to be used for a shared platform. Based on the request, a determination of eligibility of the device for a delegation of the authorization is requested. A determination of eligibility of the device for the delegation of the authorization can be received. Intermediate credentials from the sharing platform can be based on a request for the determination of eligibility of the device. A delegate file identifying an authorized approved delegate can be created based on verifying the sharing platform using the intermediate certificate.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application No. 63 / 348,858, filed on June 3, 2022, and U.S. Non-Provisional Application No. 18 / 141,886, filed on May 1, 2023. The contents of said applications are hereby incorporated by reference in their entirety. Technical Field

[0003] The present application relates to the field of networks, and in particular to granting permissions and access to devices and third parties in such networks. Background Art

[0004] Advances in cloud computing have allowed software applications to be modulated to each user's individual preferences and experiences. These users expect the ability to access any application from any location and maintain their personalized experience. To accommodate this expectation, our home, office, and travel environments are populated with Internet-enabled devices that can be used to access and enjoy each of these software applications. Summary of the invention

[0005] In some implementations, the owner may delegate the responsibility of providing a guest with a token to access one or more accessory devices at the rental property to a sharing platform, such as The sharing platform can also create a token that terminates with the visitor's reservation. In particular, the computing device can receive a request to delegate the responsibility of creating a token to access the attachment from the owner to the sharing platform. The computing device can then determine whether the attachment is eligible to delegate authorization from the owner to the sharing platform. For example, the computing device can determine whether the owner owns the device and whether the owner has not previously delegated responsibility to someone other than the sharing platform. Based on this determination, the computing device can request an intermediate certificate from the sharing platform, which can be associated with a qualified attachment. The computing device can then verify the sharing platform based on comparing the intermediate certificate to the root certificate. Assuming the sharing platform is verified, the computing device can create a delegation file that identifies the approved delegation.

[0006] In some implementations, the computing device can initially verify the sharing platform based on comparing the issuing certificate authority listed on the root certificate with a list of trusted certificate authorities. Once the computing device receives the request to approve the delegation, the computing device can retrieve the intermediate certificate from the sharing platform. The computing device can compare the intermediate certificate with the root certificate to verify that the sharing platform receiving the delegation authorization is the same sharing platform that provided the root certificate.

[0007] In some implementations, the computer may also store a delegation file. In this sense, the owner of the rental property does not have to request a delegation each time a new visitor reserves the property. The delegation file may include a delegation identifier that may be associated with the accessory(ies) or property. Each time a visitor reserves the property, the sharing platform may access the delegation file and determine that it has permission to create a token for the visitor.

[0008] Each specific implementation provides the following advantages. The owner can delegate the responsibility of creating tokens to the sharing platform, which can relieve the owner of some of the hosting responsibilities. The owner can also receive assurance that the computing device has authenticated the sharing platform and verified that the delegation is being transmitted to a valid sharing platform. The delegation to the sharing platform can also continue after the visitor's reservation. Therefore, the sharing platform can continue to create tokens for each visitor who rents the property. This arrangement enhances the visitor experience at the property and relieves the owner of the burden of tedious duties. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is an illustration of an owner-guest environment with delegated token generation authorization according to some embodiments.

[0010] Figure 2 is an illustration of an owner-guest environment with delegated token generation authorization according to some embodiments.

[0011] Figure 3 is an illustration of an owner-guest environment with delegated token generation authorization according to some embodiments.

[0012] Figure 4 is an illustration of a near field communication (NFC) system according to some embodiments.

[0013] Figure 5 is an illustration of a certificate chain according to some embodiments.

[0014] Figure 6 is an illustration of a token according to some embodiments.

[0015] Figure 7 is a signaling diagram of a delegation process according to some embodiments.

[0016] Figure 8 is a signaling diagram of a configuration process according to some embodiments.

[0017] Fig. 9 is a signaling diagram of a configuration process according to some embodiments.

[0018] Fig.10 is a flow diagram of a delegation process according to some embodiments.

[0019] Fig.11 is a flow diagram of a configuration process according to some embodiments. DETAILED DESCRIPTION

[0020] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to those skilled in the art that some embodiments may be implemented without these specific details. In addition, well-known features may be omitted or simplified to avoid confusing the described embodiments.

[0021] The development and proliferation of sharing platforms has enabled owners to negotiate the use of their assets with members of the public. Individuals can now Sharing platforms such as , have enabled these same owners to provide experiences such as car service and hospitality that were once reserved for professional service providers. In addition, advances in consumer technology have enabled these same owners to provide new technology-based experiences to their guests. This new technology can be provided through devices that can be integrated into the owner's belongings. For example, the owner's home can be equipped with smart locks, smart thermostats, and other experience-enhancing accessories. Guests can enjoy each of these accessories to enhance their rental experience.

[0022] In most cases, both owners and visitors use sharing platforms to provide and rent property without much (if any) direct interaction with each other. Therefore, one problem for owners may be to provide their visitors with access to these experience-enhanced accessories while minimizing the owner's involvement. In many cases, the owner maintains control of the experience-enhanced accessories, even when the visitor stays at the owner's property. This includes the ability to adjust the settings of the experience-enhanced accessories. Typically, a visitor may want to adjust one or more settings of the experience-enhanced accessories. However, the software executed on the device may only respond to the owner's device and therefore not to any visitor. Therefore, if a visitor wants to adjust the accessory settings, the visitor can contact the owner and let the owner remotely control the settings. For example, if the owner has a smart thermostat installed and has locked the thermostat to a specific temperature range, whenever the visitor wants to change the temperature outside the range, the visitor may need to contact the owner to remotely control the thermostat. This is a tedious process and is not always practical based on the owner's convenience. Using the above embodiment, if a visitor wants to adjust the temperature at 11:00 p.m., the owner may fall asleep and may not receive the message until the next morning. If the owner is inconvenienced and the visitor cannot sleep due to the temperature, this may make the visitor's perception of the rental experience negative. The visitor may further leave a bad review of the owner on the sharing platform, which may lead to reduced bookings for the owner.

[0023] The embodiments described herein solve the above-mentioned problem of allowing the owner to delegate the responsibility of token generation to a third-party service (such as a sharing platform). The owner can use their user device (such as a smartphone or laptop) to request that the sharing platform assume the owner's responsibility to generate a token for one or more of the owner's accessories. The sharing platform can be used via a client application (such as an Apple ) to process the request. The client application can communicate with a software framework application for managing the environment (such as Apple's ). The client application can generate a prompt asking the owner for which accessories or belongings they want to delegate token generation to the sharing platform. The client application can transmit a request for each selected device to an application server associated with the software framework, such as an Apple delegation server.

[0024] The delegation server can then communicate with the software framework server to determine whether the owner has authorization to delegate token generation authorization to the sharing platform. The delegation server can request the software framework server to check the owner's qualifications and request a challenge, where the challenge is a randomly generated number. The software framework server can verify that the owner is qualified to delegate responsibility and generate a challenge. For example, the software framework server can determine whether the owner has registered any of the selected accessories with the software framework. In the case of an Apple device, the owner may have registered one or more of the experience-enhancing accessories to be used through Apple The application monitors and / or controls these accessories.

[0025] The trust server can also confirm the sharing platform as a legitimate sharing platform. The trust server may have previously received a root certificate, such as a secure socket layer (SSL) root certificate, from the sharing platform. The trust server can verify the sharing platform by comparing the certification authority (CA) of the root certificate with a list of trusted CAs.

[0026] The delegation server can negotiate directly with the sharing platform server to delegate the token generation authorization from the owner to the sharing platform server. Responsibility can also be anchored to an asset, such as a rental property populated by an attachment, via an intermediate certificate. The intermediate certificate can be generated by the sharing platform and signed using a signature from a root certificate. The intermediate certificate can verify that the owner has the delegation token generation authorization for the attachment or property. Therefore, once the sharing platform server assumes responsibility, the delegation is passed from one visitor to another until the owner revokes the delegation or deletes the property from the sharing platform.

[0027] Visitors can use the shared platform (e.g. The sharing platform server may also transmit the token to an application executing on the visitor's user device (e.g., Apple Watch executing on the visitor's smartphone). ). The app may store the token for use by the visitor during their stay at the owner's property.

[0028] During the visitor's stay at the owner's property, the visitor may access the application through their user device, which may transmit the token to an intermediary device that may validate the token. The device may receive the token, validate the token, and allow the visitor to exercise control over one or more accessories in accordance with any owner-imposed restrictions included in the token. The token may co-terminate with the visitor's reservation, and thus expire when the reservation ends.

[0029] Figure 1 is a diagram of an owner-guest environment 100 according to some embodiments. An owner (not shown) may own a home 102 and share the home through a sharing platform such as ) to make it available. House 102 may include one or more accessories, including a first accessory 104, a device 106 (such as a resident device), and a second accessory 108. Each accessory may be integrated into the owner-visitor environment 100 and enhance the visitor experience. The first accessory 104 may be, for example, a smart lock; and the second accessory 108 may be, for example, a smart thermostat. Each of the accessories may be owned by the owner and include software that limits access to the accessory. It should be understood that the number and nature of accessories present in house 102 are illustrative, and in implementation, assets may include any number of any type of accessories. Visitor 110 may book house 102 through a sharing platform. For example, visitor 110 may access the sharing platform and browse available belongings and select the owner's house 102 to book.

[0030] The owner may delegate authorization to generate tokens to the sharing platform. Based on the delegation, the sharing platform server 112 may generate a token for one or more attachments and transmit the token to the visitor's user device 114. The visitor 110 may use their user device 114 to present the token to the device 106 (e.g., Apple ) to verify the token and access one or more attachments. Device 106 can verify the signature of the token and determine whether the guest has been granted access to one or more attachments. It is conceivable that the owner does not delegate to the guest 110 the authorization of the sharing platform to grant access to all attachments. Therefore, the owner's delegation can be attachment-specific or property-specific.

[0031] User devices 114, such as smart phones, may include, for example, Apple An application that can store a token for accessing the attachment. The application can receive the token from the sharing platform server 112 based on the visitor's reservation of the house 102.

[0032] The shared platform server 112 may include one or more interconnected computing devices that implement one or more shared platform applications or services. For example, the shared platform server 112 may store and generate tokens. The computing devices included in the shared platform server 112 may be in one or more data center environments.

[0033] return Figure 1 , the house 102 may be protected by a first accessory 104 (e.g., a smart lock) that requires a password communication to lock or unlock. The owner may make the sharing platform server 112 responsible for generating a password communication (e.g., a pass) for the visitor to access the first accessory 104. The visitor may book the house 102 via the sharing platform server 112, which in turn receives reservation details such as the visitor's identity, the reservation start date, and the number of days of stay. Based on the reservation, the sharing platform server 112 may generate a password communication for the visitor 110 to lock or unlock the first accessory 104. The sharing platform server 112 may also transmit the password communication to an application executed on the visitor's user device 114. For example, the sharing platform server 112 may transmit the password communication as part of a message to the visitor 110 who confirmed the reservation. It should be understood that traditionally, the visitor 110 will access the first accessory 104 by receiving a code directly from the owner. The visitor 110 may then manually enter the code into the first accessory 104. In some instances, the visitor 110 may also need to download an application from the manufacturer of the first accessory 104 on their user device 114. The visitor 110 will then open the manufacturer's application, and the manufacturer's application will transmit the code provided by the owner to the first accessory 104. As described above, this process is tedious because the owner must continuously create a new password each time a new visitor reserves the home 102.

[0034] In some instances, the first accessory 104 and the user device 114 can be equipped with short-range radio technology, such as near field communication (NFC) technology. The first accessory 104 and the user device 114 can detect each other based on their proximity. The detection can be based on coupling the first accessory 104 and the user device 114 via an electromagnetic field generated by the user device 114. The user device 114 can also open a secure communication channel with the first accessory 104 based on the detection. The user device 114 can also participate in a cryptographic flow in which the first accessory 104 verifies the authenticity of the signature of the data sent by the user device 114 to operate the first accessory 104. In some embodiments, the data transmitted by the user device 114 can be a pass received from the sharing platform server 112. The owner can also authorize the sharing platform server 112 to generate the pass and transmit it to the user device 114. Based on this confirmation, the first accessory 104 can allow the visitor 110 to control the first accessory 104 via the user device 114. About Figure 4 Communication between first accessory 104 and user device 114 via NFC technology is discussed in more detail.

[0035] Figure 2 200 is an illustration of an owner-visitor environment 200 according to some embodiments. As described above, an owner may own a home 202 and make the home 202 available to a visitor 204 via a property sharing platform. As shown, the home 202 may include a device 206 and one or more accessories 208. Figure 2 and Figure 1 The difference is that visitor 204 has entered house 202. Device 206 can be a resident device (e.g., Apple ), which can be a computing device designed to execute a software framework (including software that can be configured by the software framework) and operable to execute the software framework. For example, if the software framework is Apple The device can be Apple Device 206 can communicate between user device 210 and one or more accessories 208 .

[0036] It should be understood that for illustrative purposes, device 206 may be a smart speaker and one of the one or more accessories 208 may be a smart thermostat, and each may be embodied in different forms. Thus, the functionality described below with respect to a smart speaker or a smart thermostat may be applicable to different embodiments. For example, device 206 may be a laptop and one of the one or more accessories 208 may be a smart fan, wherein the laptop may include the functionality of a smart speaker, and the smart thermostat may be replaced with a smart fan, wherein instead of adjusting the temperature, the rotational speed of the fan may be adjusted.

[0037] The visitor 204 may have a user device 210, such as a smart phone, which the visitor 204 may use to present a token to access one or more accessories in the premises 202. The user device 210 may be the same user device that the visitor 204 uses to unlock the smart lock to enter the premises 202. The user device 210 may include an application that may receive the token from the sharing platform server 212 and store the token to access the one or more accessories via the device 206. The application may receive the token from the sharing platform server 212 in response to the visitor 204 reserving the premises 202.

[0038] The owner of the house 202 may have previously requested that the sharing platform server 212 assume responsibility for generating tokens for one or more accessories. Based on the request, the sharing platform server 212 can generate corresponding tokens for accessing the one or more accessories 208. The sharing platform server 212 can transmit the token to the application on the user device 210. The device 206 can receive the token from the user device 210 to verify the token. The device 206 can communicate with the one or more accessories 208 to grant permissions to the visitor based on the verified token.

[0039] Back to Figure 2 , the visitor 204 may have reserved the home 202 from the owner using the sharing platform server 212. The home 202 may include a device 206 and one or more accessories 208. The device 206 and the one or more accessories 208 may be configured such that communications from the user device 210 to the one or more accessories 208 are conveyed by the device 206. Thus, communications from a user device (such as the user device 210) to the one or more accessories 208 are directed through the device 206, which transmits the communications from the user device 210 to the one or more accessories 208. For example, the device 206, the one or more accessories 208, and the user device 210 may each include an instance of a software framework for managing accessories, such as Apple or Google The software framework can include a transport protocol that directs all communications from user device 201 to one or more accessories 208 through device 206 .

[0040] The sharing platform server 212 can generate a token for one or more accessories (e.g., including a smart thermostat). The sharing platform server 212 can also transmit the token to an application executing on the user device 210. The application can be an application for storing passwords and is different from a software framework. For example, the application can be an Apple or Google Visitors 204 can receive a token to operate one or more accessories 208 from a sharing platform server 212 via their user device 210. Visitors 204 can use an application on the user device 210 to present the token to device 206, which can verify the token. Based on the verification, device 206 can communicate with one or more accessories to allow visitor 204 permissions.

[0041] Device 206, one or more accessories 208, and user device 210 can be connected to a network, such as a local area network (LAN) or WiFi network associated with house 202. Each device can also be associated with a software framework. For example, user device 210 can include an instance of the software framework. User device 210 can also detect device 206 and one or more accessories 208 based on being connected to the same network. In addition, the owner may have allowed another instance of the software framework to manage both device 206 and an accessory (e.g., a smart thermostat). For example, guest 204 has Apple on user device 210. Instances of Device 206 and one or more accessories 208 are registered.

[0042] In some instances, the visitor 204 can control one or more accessories 208 via the user device 210, and in other cases, the visitor 204 can control the accessories through manual input. The token can also be configured to expire after a time frame to prevent the visitor 110 from accessing the smart lock after the subscription has expired.

[0043] Reference Figure 2 , a visitor 204 can enter a house 202 including a device 206 and one or more accessories 208. An accessory in the one or more accessories 208 can be, for example, a smart thermostat, a smart fan, or a smart garage door opener. As shown, one or more accessories 208 in the house 202 can be a smart thermostat. When the visitor's user device 210 is connected to the network of the house, the device 206 can detect the user device 210. The user device 210 can transmit a token to the device 206. The device 206 can verify the token to implement access control to the one or more accessories 208. The visitor 204 can control each of the one or more accessories 208 using their user device 210 or through manual input.

[0044] Figure 3300 is an illustration of an owner-visitor environment 300 according to some embodiments. As described above, an owner may own a home 302 and make the home 302 available to a visitor 304 through a sharing platform. As shown, the home 302 may include one or more accessories 306, such as a smart thermostat, a smart garage door, or a smart fan. As shown, one or more accessories 306 may be a smart thermostat. Figure 3 and Figure 2 The difference is that the house 302 does not include an intermediary device (e.g., device 206), and therefore, communications between the user device 308 and one or more accessories 306 are not conveyed by the device.

[0045] The visitor 304 may have a user device 308, such as a smart phone, which the visitor 304 may use to access the one or more accessories 306. The user device 308 may be the same user device that the visitor 304 uses to access the lock to enter the premises 302. The user device 308 may include an application that may store a token for accessing the one or more accessories 306. In response to the visitor 304 reserving the premises 302 through the sharing platform server 310, the application may receive the token from the sharing platform server 310.

[0046] The visitor 304 may have reserved the home 302 from the owner using the sharing platform server 310. The owner may have requested that the sharing platform server 310 assume responsibility for granting the visitor 304 access to one or more accessories 306. Based on the visitor's 304 reservation of the home 302, the sharing platform server 310 may generate a token for the visitor 304 to access one or more accessories 306 (e.g., a smart thermostat). The sharing platform server 310 may also transmit the token to the user device 308.

[0047] Visitors 304 can access one or more accessories 306 using a token stored on their user device 308. As shown, house 302 does not include a device for directing communications to one or more accessories 306, and thus user device 308 can communicate directly with one or more accessories 306. User device 308 can detect one or more accessories 306. For example, user device 308 and one or more accessories 306 can be connected to the same network. User device 308 and one or more accessories 306 can further communicate. The communication can be, for example, direct communication, such as via a Bluetooth-enabled transmission protocol. The communication can also be, for example, via an Internet connection. For example, assuming that one or more accessories 306 can communicate via the Internet, visitor 304 can download an application associated with one or more accessories 306 and communicate via a server associated with the smart thermostat.

[0048] Reference Figure 3, a visitor 304 may be in a home 302 that includes one or more accessories 306, such as a smart thermostat. A sharing platform server 310 may transmit a token to a user device 308. The user device 308 may transmit the token to the one or more accessories 306. The one or more accessories 306 may verify the token received from the user device 308. The visitor 304 may control the one or more accessories 306 based on the verification using their user device 308 or through manual input.

[0049] Figure 4 4 is an illustration of NFC communication 400 according to some embodiments. NFC is a short-range radio technology standard for communication between two devices in close proximity (e.g., three inches). A sharing platform server 402 may be connected to a network 404 and communicate with a user device 406 via the network 404. The network 404 may be, for example, the Internet, and the user device 406 may be a smartphone. The user device 406 may communicate with an accessory 408 equipped with an NFC tag 410. The accessory 408 may be, for example, a smart lock.

[0050] To implement NFC technology, user device 406 may include NFC controller 412, display 414, and system on chip (SoC) 416. NFC controller 412 may enable the transmitter of SoC to transmit electromagnetic field. For example, NFC controller 412 may enable AC current to be transmitted through the primary coil (e.g., transmitter) of SoC 416. Therefore, the coiled wire is capable of transmitting electromagnetic field. Conversely, NFC tag 410 may include a secondary coil, in which AC current is induced by the electromagnetic field created by user device 406. In addition to the secondary coil, NFC tag 410 may also include a small amount of memory and control instructions. Activating the NFC tag may cause attachment 408 to respond to user device 406. User device 406 may receive a response, and based on the response, user device 406 may open a secure channel with attachment 408. The user device may transmit a password communication to attachment 408 through a secure channel, and attachment 408 may grant permissions to a visitor based on the password communication.

[0051] The password communication can be generated by the sharing platform server 402 based on the owner's authorization. The visitor may have used the sharing platform to reserve the owner's belongings. Based on the reservation, the sharing platform server 402 can generate and transmit the password communication for the visitor to temporarily use the owner's smart lock.

[0052] Figure 55 is a diagram of a certificate chain 500 that includes an end-entity certificate 502 mapped to an intermediate certificate 504, and the intermediate certificate 504 is mapped to a root certificate 506. The certificate chain 500 implements trust between certificate authorities (CAs) of a public key infrastructure (PKI). This trust is based on a set of hierarchical rules that govern the interaction between the root CA, intermediate CAs, and any issued certificates (such as SSL certificates). The root certificate 506 is issued by a root (CA) (such as ) issued. In addition, a root certificate 506 signed by a known CA can establish trust between two or more devices.

[0053] As shown, the root certificate 505 includes a root CA domain name (DN) 508, a root CA public key 510, and a root CA signature 512. The intermediate certificate 504 includes a DN 514 of the issuer, where the issuer is the CA of the intermediate certificate 504, such as a shared platform. The intermediate certificate also includes a public key 516 of the issuer, a DN 518 of the root CA (which can be the same as the DN 508 of the root CA of the root certificate 506), and a signature 520 of the root CA (which can be the same as the signature 512 of the root CA of the root certificate). The DN 518 of the root CA and the signature of the root CA help establish a chain between the intermediate certificate 504 and the root certificate 506. The terminal entity certificate 502 may also include a public key 524 of the owner and a DN 526 of the issuer, which may be the same as the DN 514 of the issuer of the intermediate certificate 504. The terminal entity certificate 502 may also include a signature 528 of the issuer, and the DN 526 of the issuer helps establish a chain between the terminal entity certificate 502 and the intermediate certificate 504.

[0054] The intermediate certificate 504 is signed by the intermediate CA to use domain specific certificates. In implementation, the intermediate CA uses a certificate signed by the root CA. For example, the intermediate CA can be a sharing platform. The intermediate certificate can be used to generate a token for one or more accessories in the leased property and owned by the owner, or the intermediate certificate can be used to generate a token for all accessories in the leased property. For example, the intermediate certificate can be used to verify a request from the sharing platform to generate a token for one or more devices owned by the owner. The intermediate CA derives its authorization from the root CA and is hierarchically lower than the root CA.

[0055] The root CA uses a public key certificate that the root CA can identify. Each web browser includes a list of trusted root CAs, and therefore when a certificate is received, the web browser can verify the CA. Whether the certificate is an intermediate certificate 504 or a root certificate 506, the browser or terminal entity verifies whether the certificate includes the signature of the root CA, and whether the root CA is a trusted CA. If the certificate does not include the signature of the root CA or the root CA is not included in the list of trusted CAs, the certificate will not pass. In some instances, the certificate chain 500 includes more than one intermediate certificate, for example, a sharing platform can sign a contract with a third party. In any case, the browser or terminal entity will follow the certificate chain back until the root CA is identified. Then, the browser or terminal entity will use the list of trusted root CAs to check the identified root CA.

[0056] The software framework server can initiate an SSL connection to an end entity with a certificate signed by an intermediate CA. In some instances, the end entity can be a server of a sharing platform, and the intermediate certificate can be accessory-specific and generated specifically for one device or set of accessories owned by the owner, or in some instances, a property-specific certificate and can be generated for all accessories in the property. The software framework server can follow the signatures of the mapped certificates of the certificate chain until it detects a root certificate 506. The software framework server can then verify the CA that issued the root certificate 506 based on comparing the CA identity to a list of trusted CAs.

[0057] Based on verifying the CA, intermediate certificate 504 and root certificate 506, the software framework server can notify the delegation server that the shared platform server has been verified to receive the delegation of the generation of the token. Further based on the verification, the delegation server can open a secure channel with the shared platform server and complete the delegation of the generation of the token to the shared platform server.

[0058] Figure 6 600. The token 600 includes data created by the sharing platform server and used to allow the visitor to access the attachment. To create the token 600 for the visitor, the owner can delegate the responsibility to the sharing platform. After the owner delegates the responsibility, the visitor can access the attachment through the sharing platform (such as ) to make a reservation for temporary use of the owner's belongings. The sharing platform can receive the visitor's reservation details and create a token 600 based on the delegation and reservation.

[0059] The token 600 may include a header 602 for identification, a payload 604 including data describing the terms of the token 600, and a signature 606 for verifying that the token originated from a trusted source.

[0060] The header 602 may include an identification 608 of the token. The payload 604 may include one or more of the items shown. The payload 604 may include a start time when the visitor is allowed to access one or more attachments and an end time 612 when the visitor loses access to the one or more attachments. The sharing platform server may determine the start time 610 and the end time 612 based on the reservation information provided by the visitor.

[0061] The payload 604 may include a sharing platform identifier 616, which may be a unique identifier for a sharing platform. For example, a first sharing platform may be associated with a first sharing platform identifier, and a second sharing platform may be associated with a second sharing platform identifier. The sharing platform identifier may be provided by a sharing platform server. The payload 604 may also include a sharing platform identifier 616, which may be an identifier unique to an attachment or an attachment group. The sharing platform identifier 616 may be provided by the owner during the delegation request process. The payload 604 may also include a visitor identifier 618, which may be an identifier unique to a visitor. The sharing platform server may receive the visitor identifier 618 through the reservation information provided by the visitor. The payload 604 may also include a policy 620, which may be a policy for managing the use of the attachment. For example, a policy may include attachment-specific restrictions on the use of the attachment. For example, if the attachment is a smart thermostat, the policy may manage the minimum and maximum allowable temperatures.

[0062] Signature 622 may include a signature for verifying the authenticity of the token. For example, the attachment may receive a public key from the sharing platform server. The sharing platform server may use the private key to sign the token 600. The attachment may use the public key to decrypt the token. For example, if the public key does not decrypt the token, the attachment may assume that the token originated from an unauthorized entity or was modified by an unauthorized entity.

[0063] Figure 7It is a signaling diagram 700 for a user to delegate access authorization to a sharing platform according to some embodiments. Although the operations of processes 700, 800, 900, 1000 and 1100 are described as being performed by a general-purpose computer, it should be understood that any suitable device (e.g., user equipment, server equipment) can be used to perform one or more operations of these processes. Processes 700, 800, 900, 1000 and 1100 (described below) are respectively shown as logic flow charts, each of which represents a sequence of operations that can be implemented in hardware, computer instructions or a combination thereof. In the context of computer instructions, operations represent computer executable instructions stored on one or more computer-readable storage media, which perform the operations when executed by one or more processors. Generally speaking, computer executable instructions include routines, programs, objects, components, data structures, etc. that perform specific functions or implement specific data types. The order of describing the operations is not intended to be understood as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the described processes.

[0064] At 716, the shared platform server 708 may transmit the root certificate to the trust server 714. In some instances, the shared platform server 708 may transmit the root certificate to the trust server 714 via a commercial registration server (not shown). The root certificate may be a digital certificate file issued by a certification authority (CA). The root certificate may be used to verify that the shared platform is what it claims to be. The root certificate may include the name of the CA, the public key of the CA, and the signature of the CA. The trust server 714 may be a computing device server associated with the software framework. For example, if the software framework application is The trust server 714 may be an Apple server for verifying trusted devices and sources. The trust server 714 may verify the shared platform server 708 based on the root certificate.

[0065] At 718, a user (such as an owner) may initiate a delegation process using a user device 702. For example, a user may use their device to access a sharing platform application 704 (such as an Airbnb mobile application) and initiate the delegation process. For example, the sharing platform application may present a prompt via the user device 702 asking the user if they want to initiate the delegation process. The user may respond affirmatively to the prompt to initiate the delegation process. In some instances, the user does not have the sharing platform application downloaded to the user device 702 and may use their device to access a web browser to search for and reach the sharing platform website to initiate the delegation process.

[0066] At 720, the sharing platform application 704 may transmit a message to the storage application 706 to initiate the delegation process. The storage application 706 may be, for example, an application that enables a user to store certificates, coupons, tickets, etc., such as Apple or Google The sharing platform application 704 may also identify each property owned by the owner and listed via the sharing platform.

[0067] At 722, the storage application 706 may present all available possessions to which the user may delegate access authorization via the user device 702. The presentation may include a single device or a single possession including multiple devices. The presentation may be displayed on a display of the user device.

[0068] At 724 , the user device 702 transfers the selected belongings to the storage application 706 .

[0069] At 726, the storage application 706 may transmit a request to the delegation server 712 to identify the delegation requirement for generating the token. The delegation server 712 may be a computing device server associated with the software framework. For example, if the software framework application is The entrusted server 712 may be an Apple server.

[0070] At 728, the delegation server may transmit a request to determine eligibility for authorization to delegate generation of a token and a challenge.

[0071] At 730, the software framework server 710 may return a determination of eligibility and a challenge. The determination of eligibility may be a determination of whether the owner has any devices or accessories at the selected property. The determination may be based on, for example, whether the owner has registered any devices with the software framework. The challenge may be a randomly generated number, such as a 16-digit number.

[0072] At 732, the trust server 712 may request an intermediate certificate from the shared platform server 708. The intermediate certificate may be generated by the shared platform server 708. The intermediate certificate may include the name of the certificate issuer (e.g., shared platform), the public key of the certificate issuer, the name of the root CA, and the signature of the root CA.

[0073] At 734, the shared platform server 708 can return the intermediate certificate to the delegate server based on the request. The intermediate certificate can be specific to (one or more) specific accessories or belongings. For example, if the user has requested to delegate access authorization for a smart lock, the intermediate certificate can be specific to the smart lock. The root certificate can also be used to verify that the intermediate certificate is received from the shared platform server 708.

[0074] At 736 , the delegation server 712 can return the challenge, the delegation eligibility determination, and the intermediate certificate to the storage application 706 .

[0075] At 738, the storage application 706 can create a key certificate that provides the ability to verify the identity and qualifications of the user to delegate access authorization. The storage application 706 can also create a new public key.

[0076] At 740 , the storage application 706 can register the delegation of access authorization with the delegation server 712 .

[0077] At 742, the delegation server 712 may create a delegation identification in response to the registration.

[0078] At 744, the delegation server may map the delegation identity to the user identity, the shared platform identity, and the device identity in the software framework. If the user has delegated access authorization to all devices in the property, the mapping may be from the delegation identity to the user identity to the shared platform identity to the property identity, which is mapped to each device identity at the property. The delegation server may also transmit the user certificate and the intermediate certificate to the software framework.

[0079] At 746 , the software framework server 710 may retrieve the root certificate from the trust server 714 .

[0080] At 748, the software framework server 710 may verify the intermediate certificate using the root certificate. For example, the software framework server may verify that the intermediate certificate has been signed by the root certificate and that the CA identification information in the intermediate certificate matches the CA identity information in the root certificate.

[0081] At 750, the software framework server 710 may notify the delegate server 712 that the delegate creation is complete.

[0082] At 752, the delegation server may notify the sharing platform server that the delegation request has been completed. The delegation server may also provide a delegation identifier to the sharing platform server.

[0083] At 754, the delegation server 712 may notify the storage application that the delegation process is complete.

[0084] Figure 8 is a signaling diagram 800 for key generation for a sharing platform according to some embodiments. At 814, a guest may use a guest device 802 (such as a smartphone) to make a reservation for the owner's belongings through a sharing platform application 806.

[0085] At 816 , the sharing platform application 804 may transmit a request to the sharing platform server 808 to configure a token.

[0086] At 818, the sharing platform server 808 may forward the request for configuring the token to the delegation server 812. The sharing platform server 808 may also provide delegation identification based on the owner's and guest's reservation data that has been signed using the intermediate certificate.

[0087] At 820, the delegation server 812 may send and obtain permission from the owner to approve the reservation. For example, the owner may manually enter approval on their user device (not shown). The user device may receive the approval input and transmit the approval to the delegation server 812. Steps 818 and 820 may be based on the owner's preferences. For example, the owner may be provided with the option to personally approve each reservation, or to allow the sharing platform server 808 to approve reservations without input from the owner.

[0088] At 822, the delegation server 812 may create a configuration credential. The configuration credential may include instructions for generating a token and loading the token onto the guest user device. In particular, the guest may have a storage application on their user device. The storage application may be an instance of the same storage application on the owner's device. The configuration credential may include instructions for generating a token and instructions for loading the token into the storage application.

[0089] At 824 , the delegate server 812 may transmit the configuration credentials to the shared platform server 808 .

[0090] At 826 , the sharing platform server 808 may continue the configuration process, including inserting the token template identification and storing the configuration information in memory.

[0091] At 828 , the sharing platform server 808 may transmit a message to the sharing platform application 804 to complete the configuration process.

[0092] At 830, the sharing platform application 804 may transmit a request to the storage application to initiate configuration. Figure 7 The store application 706 is an application executing on the owner's user device 702. The store application 806 executes on the guest's user device 802.

[0093] At 832 , the storage application 806 may send a message to the sharing platform server 808 to create a token.

[0094] At 834 , the sharing platform server 808 may create a token.

[0095] Fig. 9 is a signaling diagram 900 for a user to delegate access authorization to a sharing platform according to some embodiments. Fig. 9 and Figure 7 The difference is that the accessory being delegated access authorization is not compatible with the software framework application. Therefore, instead of communicating with the software framework server during the delegation process, communication can be made with the manufacturer server 910. The manufacturer server 910 can be a server associated with the manufacturer of the accessory for which the token generation delegation is being sought.

[0096] At 916, the shared platform server 908 may transmit the root certificate to the trust server 714. The trust server 714 may be a computing device server designated to authenticate the shared platform. The trust server 714 may authenticate the shared platform server 708 based on the root certificate.

[0097] At 918 , the trust server 914 may transmit the root certificate to the manufacturer server 910 .

[0098] At 920, a user, such as an owner, may initiate the delegation process using the user device 902. For example, the user may use their smartphone to access the sharing platform application 904 and initiate the delegation process.

[0099] At 922, the sharing platform application 704 may transmit a message to the storage application 706 to initiate the delegation process. The storage application 706 may be executed on the user device 902 and may be, for example, an application that enables a user to store certificates, coupons, tickets, etc., such as Apple

[0100]

[0101] At 924, the storage application 906 may present all available belongings for which the user may authorize delegation token generation via the user device 902. The presentation may include belongings including multiple devices.

[0102] At 926 , the user device 702 may transfer the selected belongings to the storage application 906 .

[0103] At 928, the storage application 906 may transmit a request to the delegation server 912 to identify the delegation requirements for generating the token. The delegation server 912 may be a computing device server associated with the storage application 906. For example, if the storage application is The entrusted server 912 may be an Apple server.

[0104] At 930 , the delegate server 912 may transmit a request to the manufacturer server 910 to determine eligibility for authorization to delegate generation of tokens and a challenge.

[0105] At 932, the manufacturer server 910 can return a determination of eligibility and a challenge to the trust server 912. The determination of eligibility can be based on, for example, whether the owner has registered any accessories with the manufacturer, or whether the manufacturer has any record of purchasing accessories. The challenge can be a randomly generated number.

[0106] At 934, the trust server 912 may request an intermediate certificate from the shared platform server 908. The intermediate certificate may be generated by the shared platform server 708. The intermediate certificate may include the name of the certificate issuer (e.g., shared platform), the public key of the certificate issuer, the name of the root CA, and the signature of the root CA.

[0107] At 936, the shared platform server 908 can return the intermediate certificate to the delegate server based on the request. The intermediate certificate can be specific to (one or more) specific accessories or belongings. For example, if the user has requested to delegate access authorization for a smart lock, the intermediate certificate can be specific to the smart lock. The root certificate can also be used to verify that the intermediate certificate is received from the shared platform server 908.

[0108] At 938 , the delegation server 912 can return the challenge, delegation eligibility determination, and intermediate certificate to the storage application 906 .

[0109] At 940, the storage application 906 can create a key certificate that provides the ability to verify the identity and qualifications of the user to delegate access authorization. The storage application 906 can also create a new public key.

[0110] At 942 , the storage application 906 can register a delegation of access authorization with the delegation server 912 .

[0111] At 944, the delegation server 912 may create a delegation identification in response to the registration.

[0112] At 946, the delegation server 912 may map the delegation identity to the user identity, the shared platform identity, and the device identity in the software framework. If the user has delegated access authorization to all devices in the property, the mapping may be from the delegation identity to the user identity to the shared platform identity to the property identity, which is mapped to each device identity at the property. The delegation server 912 may also transmit the user certificate and the intermediate certificate to the software framework.

[0113] At 948, the manufacturer server 910 may retrieve the root certificate from the trust provider and use the root certificate to verify the intermediate certificate. For example, the manufacturer server 910 may verify that the intermediate certificate has been signed by the root certificate and that the CA identification information in the intermediate certificate matches the CA identity information in the root certificate.

[0114] At 950, the manufacturer server 910 may notify the delegate server 912 that the delegate creation is complete.

[0115] Fig.10 The present invention is a process 1000 for delegating authorization to generate a token for a device. At 1002, a computing device may receive a request to delegate authorization to generate a token for a device to a sharing platform. The request may be received from a user who has registered their rental property on the sharing platform. The computing device may be a server, such as a delegation server, that serves one or more functions of a software framework that manages devices located at the owner's property.

[0116] At 1004, the computing device may request a determination of the device's eligibility for delegation of authorization. In other words, the computing device may verify that the owner has authorization to delegate token generation capabilities to the sharing platform. In some instances, the computing device contacts another server that serves the software framework. The software framework server may include a user account associated with the owner and a list of devices and accessories that the owner has registered with the software framework.

[0117] At 1006, the computing device may receive a determination of the eligibility of the device. For example, the owner may have registered a smart shower head to be controlled by the software framework. Therefore, if the owner requests that the sharing platform assume responsibility for creating a token to use the smart shower head, the software framework server may verify that the owner has pre-registered the smart shower head. The software framework server may determine that the device is eligible. However, if the owner has never registered the device on the software framework, and no other association exists, the software framework server may determine that the device is not eligible for delegation of token creation authorization.

[0118] At 1008, the computing device may request an intermediate certificate from the sharing platform. The intermediate certificate may be issued by the sharing platform and based on a root certificate for the sharing platform. The intermediate certificate may include the domain name of the root certificate CA and the signature of the CA. The intermediate certificate may also be associated with the device for which delegation is sought.

[0119] At 1010, the computing device may create a delegation file identifying the approved delegation of authorization based on the verification of the intermediate certificate. The computing device may also notify the sharing platform token that the delegation of creation of the authorization was successful. The delegation file may be associated with the delegation identification and stored in memory by the computing device. In this sense, the owner does not have to continuously delegate authorization for the device each time a new visitor rents the property.

[0120] Fig.111100 is a process for configuring a token to provide to a visitor according to some embodiments. At 1102, a computing device may receive a request for permission to configure a token for a device located at an owner's property. The request may include an intermediate certificate associated with the device. The request may be received from a sharing platform that manages reservations for the property for the owner of the property. The computing device may be, for example, a delegate server serving a software framework that manages the device located at the owner's property.

[0121] At 1104, the computing device can verify the intermediate certificate based on the root certificate of the shared platform. For example, the computing device can determine whether the intermediate certificate includes the DN of the CA that issued the root certificate and whether the intermediate certificate includes the signature of the CA that issued the root certificate.

[0122] At 1106, the computing device may create a configuration credential for the shared platform, the configuration credential including permissions for configuring a token for the device. The computing device may create the configuration credential based on verifying the intermediate certificate.

[0123] At 1108, the computing device may transmit the configuration to the sharing platform. Based on the configuration credentials, the sharing platform may create a token for the visitor.

[0124] Example

[0125] In the following sections, additional exemplary embodiments are provided.

[0126] Embodiment 1 includes a method for delegating authorization to generate tokens from an owner of a property to a sharing platform, the method comprising: receiving, by a computing device, a message including a request for delegation of authorization for generating a token for a device, the delegation to be used for the sharing platform; requesting, by the computing device, a determination of the eligibility of the device for delegation of the authorization based at least in part on the request and verification of a root certificate of the sharing platform; receiving, by the computing device, the determination of the eligibility of the device for delegation of the authorization; requesting, by the computing device, at least in part based on the determination of the eligibility of the device, from the sharing platform an intermediate certificate, the intermediate certificate being associated with the device and based at least in part on the root certificate; and creating, by the computing device, a delegation file identifying the approved delegation of authorization based at least in part on verification of the sharing platform using the intermediate certificate

[0127] Embodiment 2 includes the method of embodiment 1, wherein the method further comprises authenticating the sharing platform based on comparing the certificate authority of the root certificate to a list of approved certificate authorities.

[0128] Embodiment 3 includes the method of any one of embodiments 1 and 2, wherein the method further comprises: transmitting a request for verification of the intermediate certificate, wherein the request includes the intermediate certificate; and receiving verification of the intermediate certificate, wherein the verification of the shared platform is based at least in part on identifying a root certificate signature in the intermediate certificate.

[0129] Embodiment 4 includes the method of any one of embodiments 1-3, wherein the request to verify the intermediate certificate is transmitted to a third party manufacturer of the device.

[0130] Embodiment 5 includes the method of any one of embodiments 1 to 4, wherein the method further comprises transmitting a message to the sharing platform that the authorization for generating the token has been delegated to the sharing platform.

[0131] Embodiment 6 includes the method of any one of embodiments 1 to 4, wherein the token includes a start time and an end time.

[0132] Embodiment 7 includes the method of any one of embodiments 1 to 4, wherein the delegation file includes a delegation identification associated with the device.

[0133] Embodiment 8 includes a computing device comprising: a processor; and a computer-readable medium including instructions stored thereon, which instructions, when executed by the processor, cause the processor to perform the method of any one of Embodiments 1 to 7.

[0134] Embodiment 9 includes a non-transitory computer-readable medium including instructions stored thereon, which when executed by a processor causes the processor to perform operations including the method of any one of Embodiments 1 to 7.

[0135] Although specific embodiments have been described, those skilled in the art will recognize that numerous modifications are possible. A single controller can use the processes described herein to establish pairings with any number of accessories and selectively communicate with different accessories at different times. Similarly, a single accessory can be controlled by multiple controllers with which pairings have been established. Any function of an accessory can be controlled by modeling the function as a service with one or more characteristics and allowing the controller to interact with the service and / or the characteristics of the service (e.g., read, modify, receive updates). Therefore, regardless of the accessory function or the controller form factor or specific interface, the protocols and communication processes described herein can be "universal", meaning that they can be applied in any scenario with one or more controllers and one or more accessories.

[0136] Therefore, although specific embodiments have been described, it should be understood that the embodiments may include all modifications and equivalents within the scope of the following claims.

[0137] As described above, one aspect of the present technology is to collect and use data available from specific and legitimate sources to improve message delivery from one device to one or more devices. The present disclosure contemplates that, in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data may include demographic data, location-based data, online identification, phone number, email address, home address, data or records related to the user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other personal information.

[0138] The present disclosure recognizes that the use of such personal information data in the present technology can be used to benefit the user. For example, the personal information data can be used to deliver commands from a user profile on a computing device to one or more computing devices. In addition, the present disclosure also contemplates other uses of the personal information data that benefit the user. For example, a specific state of a device associated with the user (e.g., a healthcare-related device, a fitness device, etc.) can be transmitted from the device back to the user profile.

[0139] The present disclosure envisions that entities responsible for collecting, analyzing, disclosing, transmitting, storing or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities will be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding the requirements of the industry or government that maintain user privacy. Such information about the use of personal data should be highlighted and easily accessible to users, and should be updated as the collection and / or use of data changes. The user's personal information should be collected only for legal use. In addition, such collection / sharing should only occur after receiving user consent or other legal basis specified in applicable law. In addition, such entities should consider taking any necessary steps to protect and safeguard access to such personal information data and ensure that other entities with access to personal information data comply with their privacy policies and procedures. In addition, such entities may subject themselves to third-party assessments to prove that they comply with widely accepted privacy policies and practices. In addition, policies and practices should be adjusted for specific types of personal information data collected and / or accessed, and applied to applicable laws and standards, including considerations that are exclusive to jurisdictions that can be used to impose higher standards. For example, in the United States, collection or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0140] Regardless of the foregoing, the present disclosure also contemplates implementation schemes in which users selectively block the use or access of personal information data. That is, the present disclosure contemplates that hardware elements and / or software elements may be provided to prevent or block access to such personal information data. For example, such as with respect to a token generation service, the present technology may be configured to allow a user to choose to "opt in" or "opt out" to participate in the collection of personal information data at any time during or after registration for the service. In addition to providing "opt-in" and "opt-out" options, the present disclosure contemplates providing notifications related to access or use of personal information. For example, a user may be notified that their personal information data will be accessed when downloading an application, and then be reminded again just before the personal information data is accessed by the application.

[0141] Exemplary techniques for using a computing device to delegate authorization to generate a token from an owner to a sharing platform and for configuring the token by the sharing platform. Some or all of these techniques may be implemented at least in part by, for example, at least in the above Figures 1 to 11 , but not necessarily by them. Although many embodiments are described above with reference to computing devices and user devices, it should be understood that other types of computing devices may be suitable for performing the technology disclosed herein. In addition, various non-limiting embodiments are described in the foregoing description. For the purpose of explanation, many specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it should also be apparent to those skilled in the art that some embodiments can be implemented without these specific details. In addition, sometimes well-known features are omitted or simplified to prevent confusion with the embodiments described herein.

[0142] Various embodiments may also be implemented in a wide variety of operating environments, which in some cases may include one or more user computers, computing devices, or processing devices that may be used to operate any of a plurality of applications. User devices or client devices may include any of a number of general-purpose personal computers, such as desktop computers or laptop computers running standard operating systems, as well as cellular devices, wireless devices, and handheld devices running mobile software and capable of supporting multiple networking protocols and instant messaging protocols. The system may also include multiple workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network.

[0143] Most embodiments utilize at least one network familiar to those skilled in the art to support communications using any of a variety of commercial protocols such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. The network may be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.

[0144] In embodiments utilizing a web server, the web server may run any of a variety of server or middle-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. One or more servers may also be capable of executing programs or scripts in response to requests from user devices, such as by executing one or more applications, which may be implemented in any programming language such as One or more scripts or programs written in C, C# or C++ or any scripting language such as Perl, Python or TCL and their combinations. The server(s) may also include a database server, including but not limited to database servers that can be accessed from Those obtained commercially.

[0145] Environment can include various data storage repositories and other memory and storage media, as discussed above. These can reside in various locations, such as on a storage medium local to one or more computers or away from the storage medium of any or all computers on the network (and / or reside in one or more computers). In a specific set of embodiments, information can reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to computers, servers or other network devices can be stored locally and / or remotely as needed. When the system includes a computerized device, each such device may include a hardware element that can be electrically coupled via a bus, and the element includes, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touch screen or keypad), and at least one output device (e.g., display device, printer or speaker). Such systems can also include one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices such as RAM or ROM, and removable media devices, memory cards, flash memory cards, etc.

[0146] Such devices may also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.) and a working memory as described above. A computer-readable storage medium reader may be connected to or configured to receive a non-transient computer-readable storage medium representing a remote, local, fixed and / or removable storage device, and a storage medium for temporarily and / or more permanently containing, storing, transmitting and retrieving computer-readable information. Systems and various devices will also typically include a plurality of software applications, modules, services or other elements located within at least one working memory device, including an operating system and an application, such as a client application or a browser. It should be understood that alternative embodiments may have many variations according to those described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software, such as applets), or both. In addition, connections with other computing devices such as network input / output devices may be employed.

[0147] Non-transitory storage media and computer-readable storage media for containing code or parts of code may include any suitable media known or used in the art, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data), including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, DVD or other optical storage, cassettes, tapes, disk storage devices or other magnetic storage devices, or any other medium that can be used to store the required information and can be accessed by system devices. Based at least in part on the disclosure and teachings provided herein, a person of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments. However, computer-readable storage media do not include transient media such as carrier waves.

[0148] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the claims.

[0149] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the present disclosure to the particular forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalent forms that fall within the spirit and scope of the present disclosure as defined by the appended claims.

[0150] The use of the terms "one", "an" and "the" and similar indicators in the context of describing the disclosed embodiments (particularly in the context of the claims below) will be interpreted as covering the singular and plural, unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the terms "comprise", "have", "include" and "contain" should be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" is interpreted as being partially or completely included, attached or joined together even if there are intervening things. The phrase "at least in part based on" should be understood as open, and is not limited in any way, and is intended to be interpreted or otherwise understood as "at least in part based on" where appropriate. Unless otherwise stated herein, the description of the numerical range herein is intended only to be used as a simple method of referring to each individual value falling within the range individually, and each individual value is incorporated into the specification as quoted individually in this article. All methods described herein can be performed in any suitable order, unless otherwise stated herein or otherwise clearly contradicted by the context. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., "such as") provided herein is intended merely to better illustrate the embodiments of the present disclosure and does not limit the scope of the present disclosure. No language in the specification should be construed as indicating any non-claimed element is essential to the practice of the present disclosure.

[0151] Unless otherwise specifically stated, disjunctive language such as the phrase "at least one of X, Y, or Z" is understood in context as generally used to present an item, term, or the like that can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z each be present. Additionally, conjunctive language such as the phrase "at least one of X, Y, and Z" is also understood to mean X, Y, Z, or any combination thereof, including "X, Y, and / or Z," unless otherwise specifically stated.

[0152] Preferred embodiments of the present disclosure are described herein, including the best mode known to the inventor for carrying out the present disclosure. After reading the foregoing description, variations of those preferred embodiments may become apparent to those of ordinary skill in the art. The inventor expects that the technical staff will appropriately adopt such variations, and the inventor intends to practice the present disclosure in a manner different from that specifically described herein. Therefore, as permitted by applicable law, the present disclosure includes all modifications and equivalents of the subject matter recorded in the claims attached to the present disclosure. In addition, unless otherwise noted herein or obviously contradictory to the context, the present disclosure includes any combination of all possible variations of the above-mentioned elements.

[0153] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims

1. A method comprising: receiving, by a computing device, a message including a request for authorization for a delegate to generate a token for the device, the delegate to be used for a sharing platform; requesting, by the computing device, a determination of eligibility of the device for delegation of the authorization based at least in part on the request and verifying a root certificate of the sharing platform; receiving, by the computing device, the determination of the eligibility of the device for delegation of the authorization; requesting, by the computing device, from the sharing platform an intermediate certificate based at least in part on the determination of qualifications of the device, the intermediate certificate being associated with the device and based at least in part on the root certificate; as well as A delegation file identifying an approved delegation of authority is created by the computing device based at least in part on authenticating the shared platform using the intermediate certificate. 2 . The method of claim 1 , wherein the method further comprises authenticating the sharing platform based on comparing a certificate authority of the root certificate to a list of approved certificate authorities.

3. The method according to any one of claims 1 and 2, wherein the method further comprises: transmitting a request to verify the intermediate certificate, wherein the request includes the intermediate certificate; as well as A verification of the intermediate certificate is received, wherein the verification of the shared platform is based at least in part on identifying a root certificate signature in the intermediate certificate. The method of claim 3 , wherein the request to verify the intermediate certificate is transmitted to a third-party manufacturer of the device.

5. The method according to any one of claims 1 to 4, wherein the method further comprises transmitting a message to the sharing platform that the authorization for generating the token has been delegated to the sharing platform.

6. The method according to any one of claims 1 to 5, wherein the token comprises a start time and an end time.

7. The method according to any one of claims 1 to 6, wherein the delegation file comprises a delegation identification associated with the device.

8. A computing device comprising: processor; and A computer readable medium comprising instructions stored thereon which, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 7.

9. A non-transitory computer-readable medium comprising instructions stored thereon, which when executed by a processor cause the processor to perform operations including the method of any one of claims 1 to 7.

10. A method comprising: receiving, by a computing device, a request for permission to configure a token associated with the device, the request including an intermediate certificate generated by a sharing platform; verifying the intermediate certificate based at least in part on a root certificate of the shared platform; creating, by the computing device, a configuration credential including the permission for configuring the token for the device based at least in part on the verification of the intermediate certificate; as well as The configuration credentials are transmitted by the computing device to the sharing platform. The method according to claim 10 , wherein the intermediate certificate is generated based on a root certificate of the shared platform.

12. The method according to any one of claims 10 and 11, wherein the method further comprises: transmitting a request for permission to configure the token based at least in part on the request to configure resources for the token; receiving a response to the request for permission to configure the token; as well as The configuration credentials are created based at least in part on the response.

13. The method according to any one of claims 10 to 12, wherein the request for configuration of the token comprises subscription data, the method further comprising: identifying a start time and an end time for a reservation based at least in part on the reservation data; as well as The configuration credentials are created based at least in part on the start time and the end time of the subscription.

14. The method according to any one of claims 10 to 13, wherein the request for configuration of the token comprises a delegation identification, and the method further comprises: comparing the delegation identifier with a plurality of delegation identifiers; as well as The configuration credentials are created based at least in part on the comparison.

15. The method of any one of claims 10 to 14, wherein verification of the intermediate certificate is based at least in part on identifying a root certificate signature in the intermediate certificate.

16. The method of any one of claims 10 to 15, wherein the request to configure the token is signed using the intermediate certificate.

17. A computing device comprising: processor; and A computer readable medium comprising instructions stored thereon which, when executed by the processor, cause the processor to perform the method according to any one of claims 10 to 16.

18. A non-transitory computer-readable medium comprising instructions stored thereon, which when executed by a processor cause the processor to perform operations including the method of any one of claims 10 to 16.

Images