Establishing a data subscription for utility usage information

This application claims the benefit of U.S. Provisional Application No. 63/643,364, entitled “ESTABLISHING A DATA SUBSCRIPTION FOR UTILITY USAGE INFORMATION,” filed May 6, 2024, the entirety of which is incorporated herein by reference.

The present description relates generally to electronic devices, including, for example, utilizing an electronic device to initiate a subscription for utility usage information

As the world becomes more energy-aware and the cost of energy has increased, it has become desirable to some people to obtain and track utility usage information at, for example, their place of residence. On the utility provider side, generally utility providers welcome customer engagement in exploring usage tracking and usage cutting techniques to reduce pressure on utility transmission channels.

The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology can be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, the subject technology is not limited to the specific details set forth herein and can be practiced using one or more other implementations. In one or more implementations, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

Many users of various electronic devices rent or own a home that uses utilities, such as one or more of electricity, water, and gas. A subset of such users may utilize their electronic devices to log into a customer website or customer portal operated by the utility provider. At such customer websites, customers can view data about their usage and bills. Some customers never bother to set up their customer access to these customer portals and so do not receive usage information other than what is provided on a bill received at their mailing address or email address.

Aspects of the subject technology provide a mechanism for customers of utility providers to use their electronic devices (e.g., user devices) to subscribe to a usage data sharing service which can obtain utility usage information corresponding to the customer from a utility provider and supply that usage information eventually to the customer's device. Aspects of the subject technology further provide the ability for the utility customers to subscribe to the usage data sharing service without having to go through a customer portal of the utility provider. Indeed, in some aspects, customers accessing usage data may not even have an online account set up with the utility provider at the customer portal. The handling of private or sensitive data is considered in this process of accessing utility usage data. As such, permissions and authentication to access the utility usage data are also addressed by implementation by the subject technology.

Therefore, the subject technology advantageously improves access to and management of access to utility usage information via a user's device. This provides a solution to the inherently technical problem of authenticating a user device and authorizing the user device to access data located at a server. The solution to these issues described herein includes the use of an intermediary server which collects data from the utility server in a privacy preserving manner and provides the data to the user device in a privacy preserving manner.

illustrates an example network environmentin accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

The network environmentincludes a user device, a user device, an intermediary server, and a utility server. The networkmay communicatively (directly or indirectly) couple the user deviceand/or the user deviceto the intermediary serverand/or the utility server. In one or more implementations, the networkmay be an interconnected network of devices that may include, or may be communicatively coupled to, the Internet. For explanatory purposes, the network environmentis illustrated inas including the user device, the user device, the intermediary server, and the utility server; however, the network environmentmay include any number of user devices and any number of servers or a data center including multiple servers. In particular, in some implementations, the intermediary serverand/or the utility serverare representative of an array of servers which may be geographically diverse. In some implementations one or more of the user devicesand/or user devicesmay not be connected to the network, but may be tethered to one of the other user devicesand/orwirelessly or by a wired connection.

The user devicemay be, for example, a desktop computer, a portable computing device such as a laptop computer, a smartphone, a peripheral device (e.g., a digital camera, headphones), a tablet device, a wearable device such as a watch, and the like. In, by way of example, the user deviceis depicted as a mobile user device (e.g., smartphone). The user devicemay be, and/or may include all or part of, the electronic system discussed below with respect to.

The user devicemay be, for example, desktop computer, a portable computing device such as a laptop computer, a smartphone, a peripheral device (e.g., a digital camera, headphones), a tablet device, or a wearable device such as a head mountable portable system, that includes a display system capable of presenting a visualization of an extended reality environment to a user. In, by way of example, the user deviceis depicted as a desktop computer. The user devicemay be, and/or may include all or part of, the electronic system discussed below with respect to.

In one or more implementations, one or more of the user devicesand/ormay have an application thereon with a user interface for connecting to a utility server to obtain a subscription to utility usage information provided by the utility server to an intermediary server. The application may interact with the intermediary serverfor some processes of obtaining a subscription and may interact with the utility serverfor some processes of obtaining the subscription. The interaction between the application and the intermediary servermay include the exchange of personal information relevant to a user account associated with the intermediary server. The interaction between the application and the utility servermay include the exchange of personal information relevant to a user account associated with the utility serverfor the same user. The personal information in the one domain is handled in a privacy preserving way with respect to the other domain.

The intermediary servermay form all or part of a network of computers or a group of servers (where the intermediary serveris representative of such a group of servers), such as in a cloud computing or data center implementation. For example, the intermediary serverstores data and software, and includes specific hardware (e.g., processors, graphics processors and other specialized or custom processors) for rendering and generating content such as graphics, images, video, audio and multi-media files. In an implementation, the intermediary servermay function as a subscription data manager server which interacts with the utility serverto receive or request subscription data, organize the subscription data, and provide the subscription data to the user devicesand/or. The intermediary servermay be, and/or may include all or part of, the electronic system discussed below with respect to.

The utility servermay form all or part of a network of computers or a group of servers (where the utility serveris representative of such a group of servers), such as in a cloud computing or data center implementation. For example, the utility serverstores data and software, and includes specific hardware (e.g., processors, graphics processors and other specialized or custom processors) for rendering and generating content such as graphics, images, video, audio and multi-media files. In an implementation, the utility serveris associated with a utility provider where a user maintains a utility account and where usage data is available for the user utility account, and the utility servermay function to authenticate the user deviceand/orto receive utility usage information for the user associated both with the user deviceand/oras well as the utility provider. In an implementation, the utility servermay provide anonymized utility usage data to the intermediary serveraccording to a subscription authentication set up between the user deviceand/or. The utility servermay be, and/or may include all or part of, the electronic system discussed below with respect to.

In the example of, each of the user devicesandare depicted as a particular type of device, e.g., smartphone and desktop or portable computer. However, it is appreciated that each of the user devicesandmay be implemented as another type of device, such as a wearable device (e.g., a smart watch or other wearable device). The user devicesand/ormay be a device of a user (e.g., the user devicesand/ormay be associated with and/or logged into a user account for the user at a server, such as the intermediary server).

illustrate data flowbetween a user device, an intermediary server, and a utility serverfor registering the user deviceto receive a subscription for utility usage information from the utility serverin accordance with some implementations. For the sake of simplicity, unless otherwise noted, where the description below refers to the user device, it should be understood that the user devicemay be used. The intermediary servermay be an intermediary server such as the intermediary serverdescribed above. The utility servermay be utility server such as the utility serverdescribed above. It should be appreciated that more or fewer data exchanges between the user device, the intermediary server, and the utility servermay be used than those described herein. For example, some data exchanges may be optional and some data exchanges may be repeated if, for example, the data exchange fails for whatever reason. For the sake of simplicity, unless otherwise noted, an action taken at the user deviceshould be understood to be taken by accessing an application installed on the user deviceor a system setting or configuration of the user device. In some implementations the application may be an add-on application, such as installed from an application store and developed by a third-party. In other implementations the application may be a native application, such as an application provided by the device manufacturer.

At, the user devicereceives a request at the user devicefor setting up access at the user deviceto receive utility usage information from a utility provider for a customer of the utility provider where the customer of the utility provider is the same individual as the user of the user device. The user of the user devicemay be logged into the user deviceor to an application running on the user deviceusing credentials which are tied to a user account associated with the user deviceor the application running on the user device. The same user account may also be associated with the intermediary server. The request can come to the user device, for example, from the user of the device by launching an application or a configuration setting of the user deviceand selecting an option to set up a subscription for utility usage information.

At, a token is requested by the user devicefrom the intermediary server. As noted above, the intermediary servermay include a collection of servers, for example, on the same physical device or on separate devices under the control of the same entity. One of such servers may be a second server including an authorization server which generates the token and ultimately provides the token to the user deviceeither directly or through another one of the servers of the intermediary server. Thus, at, the token is generated by the intermediary server, and at, the token is provided from the intermediary serverto the user device. Obtaining a token in this manner is optional in some implementations. The token may represent that the user device or the user account associated with the device is also associated with the intermediary server. For example, the token may represent that some user information associated with the user account at the intermediary serverhas been verified. The token itself may include some encrypted data which may include some encrypted personal information, some encrypted account information for the user account, or some encrypted device information for the user deviceassociated with the intermediary server. By generating and sending the token to the user devicefrom the intermediary server, the intermediary serveris signaling that the user, the user device, and/or the account associated with the user are verified and/or trusted. This can help prevent the utility serverfrom being bombarded with invalid requests or phishing attempts.

At, if a token is received then the token can be sent from the user devicedirectly to the utility server. If the token is not used, then other user information can be sent to the utility server. For example, the user information sent to the utility servermay be the phone number associated with the mobile device, if the user deviceis a mobile device, or may be a user identifier (ID) associated with the user account corresponding to the intermediary server.

At, the utility servercan validate the token or user information. In some implementations, the validation can be performed by using a public key to verify the cryptographic signature of the token to determine that the token is valid or use a private key to decrypt the token to verify that the token was valid. In other implementations, such as that provided for in, the token or user information can be provided to the intermediary serverfrom the utility server.

At, the intermediary servercan verify the token (if a token was used) and return a response to the utility serverthat the information was valid. This in-turn establishes that the request (at) is allowed to proceed. To verify the token, the intermediary servercan use the public key to verify the token or can use a private key to decrypt the token (since it issued the token at). If the verification passes, then the flow can proceed to, otherwise, an alternative flow can be utilized to set up the subscription service for utility data. In other implementations, for example, if the user provided user information to the utility serverrather than a token, the intermediary servercan verify the user information (e.g., such as a user ID, phone number, account number, or the like), by utilizing the user information to determine if the information provided matches records associated with the intermediary server.

At, the utility servercan provide requests for account-identifying information for the user to provide at the user device. The request for account-identifying information may be provided either directly to the user deviceor to the intermediary server, which can then provide the request for account-identifying information to the user device. The request for account-identifying information establishes a fingerprint identification by having the user devicerespond to the request for account-identifying information back to the utility serverto provide information to the utility serverwhich is associated with the customer account at the utility server. For example, the utility servermay query the user devicefor information found on the most recent billing statement, information regarding payment methods or amounts for the most recent payment to the utility account, information regarding length of service, information regarding a meter serial number associated with the account, information regarding an email address, phone number, or other contact information of the customer, so forth, and combinations thereof. Such information may only be known at the utility serverand by the user associated with the user device. The questions can be displayed at the user device, thereby prompting the user to answer the questions.

In some implementations, the intermediary serverand utility servercan have an agreement to provide to the user device, from the intermediary server, the request for account-identifying information. The request for account-identifying information, for example, may be from a pool of questions by prearrangement between the intermediary serverand the utility server. The user device can provide to the user pre-filled information in the fields corresponding to the request for account-identifying information. The information which is pre-filled may, for example, be stored at the user device and be associated with user contact information stored at the user device, such as email, phone, address, and so forth. The user may modify the pre-filled data with different data, for example, if the user's utility account uses an alternative phone number or email address and so forth. Notably, the request for account-identifying information may not provide masked user data for the user to verify or select from, but provides prompts for the user to provide identifying information for the user deviceto send directly back to the utility sever.

At, the user devicecan send the responses for the request for account-identifying information to the utility server. Because the answers to the questions may contain sensitive or personal information, the responses can be sent directly to the utility server, rather than, for example, the intermediary server. This protection of sensitive or personal information ensures the intermediary serverdoes not access such information when it is not needed.

In some implementations, the stepsandcan be performed in the same operation. Recall that the request for account-identifying information atmay include a request for certain information by a prearrangement between the intermediary serverand utility server. In such instances, rather than send the token and get permission to proceed from the utility server, the intermediary servercan prompt the user devicefor the account-identifying information at, then when the user devicesends the response with the account-identifying information at, the user devicecan also send the token information at. The token can be validated at/along with the account-identifying information to determine and validate the customer associated with the utility serverand user device. In one or more implementations, one or more ofand/ormay include a one-time passcode verification.

At, after the utility serverreceives the responses from the user deviceto the request for account-identifying information, the utility servercan identify the user account and verify the supplied user account information for the utility customer using the provided account-identifying information to verify the user (e.g., the identity of the user). After identifying the user account associated with the utility serverand verifying that the information provided in the account-identifying information matches the account information stored at the utility serverto verify the user identity, the utility servercan generate a validation code and send the validation code to the user of the user device. The validation code can be used to separately verify that the customer of the utility serverand/or user deviceis authenticating with the utility server. In some implementations this may be optional.

In some implementations, generating and sending the validation code may include prompting the user device to choose a delivery mode for the validation code. For example, the user may be prompted to choose to send the code to the email address or phone number associated with their utility account. The validation code can be a one-time code or other type of code that can be generated and sent from the utility serverto the user of the user device. The validation code can be sent to a trusted contact information for the user, for example, selected from the customer record of the utility serverthat corresponds to the user. Thus, in some implementations, the validation code can be sent to the user and/or user devicethrough a communication mechanism other than the communication mechanism by which the other messages are being sent. For example, if the user deviceis a smart phone which is interacting with the utility serverby accessing an application or configuration setting on the user device, then a communication mechanism other than the interface of the application or configuration setting may be email, text message, or a system notification. Notably, the same user devicecan receive the validation code except through a different application or unlocking. In some implementations, the validation code can be provided to a device other than the user device. For example, the validation code can be sent as a voice call to a phone number associated with the customer account at the utility serveror may be received in email on another device other than the user device.

At, the validation code can be received by the user and/or at the user device, for example, by an application or system process of the user device, when received at the user device. Then, at, an entry or prompt can be provided or displayed at the user devicefor the user to enter the validation code received at the user device. In some implementations, the entry or prompt can be provided or displayed at the user deviceprior to receiving the validation code. Receiving the validation code at the user device, at, can include the user providing the code to the user device, where the user receives the validation code at the user deviceor at another device. At, the user devicesends the validation code back to the utility serverto complete the authentication of the user and/or user deviceto the utility server.

After the validation code is verified, the process can continue toor can skip to. The stepstocan be performed to support some legacy systems that use authorization codes. In such systems, at, the utility servercan send an authorization code to the user device. The authorization code signifies that the process described to this point has been completed. Essentially, the authorization code signifies that the subscription is ready to be set up and that the bearer of the authorization code has the authorization to access the subscription data. That is, after the completion of the data flowup through, the user has been validated by both the intermediary serverand the utility server. Also, the user devicehas optionally been authenticated or verified that it belongs to the customer of the utility server. The remaining elements ofare provided for setting up the subscription. A particular implementation for doing this is described below, however, it should be appreciated that other approaches may be used. One of the considerations involved in this process is that the subject technology may establish a subscription model where the subscription may be revoked by any of the parties involve. As such, as a part of establishing the subscription an access token is used to maintain permissions between the various device elements (e.g., user device, intermediary server, and utility server) to interact with each other without having to reauthenticate or revalidate.

Aspects of the subject technology provide that the utility companies provide the utility usage information to the intermediary serverand then the intermediary serverprovides the usage information to the user device, rather than have the utility serverprovide the utility usage information directly to the user device. There are several advantages to implementing the subscription model as provided for in the subject technology. One advantage is that the user associated with the user devicecan access utility usage information for their customer account(s) without needing online access to a customer portal of the utility server. Further, the user can obtain aggregated data from multiple utilities providers at the intermediary server(since each utility serveris different for each different utility provider). Another advantage is that if the utility provider sent utility usage information directly to the user devices, then the utility serverwould be managing the provision of the data to each user device. By utilizing the intermediary serveras an intermediary, the management burden on the utility serveris less. Another advantage is that the intermediary servermay be able to aggregate data in an anonymized way from multiple utility providers across many servicing areas. This gathered data can be used to help understand energy needs in various servicing areas. It should be understood that this data could be gathered in a way that protects the privacy of personal information associated with the data. It should also be understood that this data would be gathered and collected with permission.

After receiving the authorization code at the user device, at, the user devicesends the authorization code to the intermediary server, which sends, at, the authorization code to the utility server. Receiving the authorization code back at the utility serverindicates that the user deviceand the intermediary serverhave permission to access the utility usage information at the utility server.

As noted above,may proceed after the verification of the validation code received at the utility serveror may proceed after verifying the authorization code following. As such, at, the utility servergenerates an access token and provides the access token to the intermediary server. The intermediary serverstores the access token atand provides, atthe access token to the user device. In one or more implementations, the access token may be temporarily stored on the intermediary server, until it can be delivered to the user device. The user devicestores the access token at. In some implementations, to further heighten security of the access user data, the access token is provided directly to the user devicefrom the utility serverand not sent to or stored by the intermediary server.

In, the data flowcontinues. With the access token procured, the user device, at, requests a subscription from the intermediary server. Then, the intermediary server, in turn at, requests a subscription from the utility server. The utility servercan check the customer account (the customer account being tied to the access token) to determine if multiple services are provided for the customer account. For example, if the utility service is an electricity provider, then the customer of the electricity provider may have multiple service addresses and/or multiple electric meters associated with their account. In such instances, at, the list of service locations and/or service meters may be provided to the intermediary server.

At, the list of service locations and/or meters can be provided to the user device. The user devicemay display to the user the list of service locations and/or meters associated with their customer account and provide an interface to allow the user to select one or more locations to add to obtain the utility usage data from.

At, the user may make a selection at the user devicefor which of the service locations and/or meters to subscribe to utility usage information. In some implementations, the user must pick a single service location and/or meter, and in other implementations, the user can pick several locations and/or meters. In some implementations, the ability to pick one or multiple service locations and/or meters may be based on a service level the user has with the intermediary serverand/or utility server.

At, the user's selection(s) may be sent to the intermediary serverfrom the user deviceand the intermediary server can, at, send the user's selection(s) to the utility server. The utility servercan assign a subscription ID to the customer and tie the subscription ID to the selected service location and/or meter for utility usage data monitoring as well as to the access token. It should be understood that if the customer only has one service location and/or meter, then the process elements of-may be omitted and the utility servercan tie the subscription ID to the only service location and/or meter available as a default process as well as to the access token.

At, the subscription ID is sent from the utility serverto the intermediary server. At, the intermediary serverassociates the subscription ID in some manner to the user. This may be accomplished in a variety of ways. For example, the subscription ID may be associated with a user account corresponding to the user, in one implementation. In another implementation, however, it is realized that the intermediary serverneed not directly associate the subscription ID with the user. Instead, the subscription ID can be associated with a data storage area managed by the intermediary serverand the user devicemay be given permission to access the data storage area associated with the subscription ID. As a result, to the extent that the utility usage information may be considered personally identifiable information if associated with a particular user, instead the utility usage information can be kept separated from the user information at the intermediary server. At, the subscription ID is sent to the user device.

At, when utility usage information is provided by the utility server, it may be provided in a batch file along with the utility usage information for all other subscribers. The batch file may also include the corresponding subscription ID for each record sent in the batch file.

At, the intermediary servercan separate the records by subscription ID to provide to a user deviceassociated with that subscription ID. In accordance with some implementations the utility usage records associated with a particular subscription ID can be stored at the intermediary server(or a storage device or service associated with the intermediary server) and the user devicemay be provided access to retrieve the utility usage information.

At, the user devicemay receive the utility usage information corresponding the subscription ID. If more than one service location and/or meter is associated with the subscription ID, the user deviceand/or intermediary servercan further separate the utility usage information by service location and/or meter information.

illustrate data flow, data flow, and data flow, respectively. Each of these data flows deals with subscription management for the subscription to the utility usage information. The data flows,, andmay be between a user device, an intermediary server, and a utility serverfor managing the subscription of the user deviceto receive utility usage information for a customer account associated with the utility serverin accordance with some implementations. For the sake of simplicity, unless otherwise noted, where the description below refers to the user device, it should be understood that the user devicemay be used. The intermediary servermay be an intermediary server such as the intermediary serverdescribed above. The utility servermay be utility server such as the utility serverdescribed above. It should be appreciated that more or fewer data exchanges between the user device, the intermediary server, and the utility servermay be used than those described herein. For example, some data exchanges may be optional, and some data exchanges may be repeated if, for example, the data exchange fails for whatever reason. For the sake of simplicity, unless otherwise noted, an action taken at the user deviceshould be understood to be taken by accessing an application installed on the user deviceor a system setting or configuration of the user device. In some implementations the application may be an add-on application, such as installed from an application store and developed by a third-party. In other implementations the application may be a native application, such as an application provided by the device manufacturer.

illustrates a data flowfor sending a request to cancel the subscription from the user deviceto the intermediary serveror to the utility server. At, a request can be provided to the user deviceto cancel the subscription for the utility usage subscription. In some instances, the request can be received by a user of the user device, while in other instances, the request may be received by an automated process on the user device, for example, an automated process resulting from deleting an application used for storing utility usage information.

At, in implementations where the cancellation request is sent to the intermediary server, the user devicesends the cancellation request to the intermediary server. Then, at, the cancellation request is sent from the intermediary serverto the utility server.

Alternatively, at, in other implementations the cancellation request may be sent from the user deviceto the utility server.

At, the utility servercancels the subscription so that it will no longer be included in the batch file. In some implementations, the utility servercan mark the subscription inactive for a time period before cancellation is completed. In both instances, however, the utility usage information is not included in the batch file.

At, the access token that was previously supplied by the utility servercan be revoked so as to be invalidated. Once the access token is revoked then, if the user devicewanted to access utility usage information, the user devicemay need to go through the process again to obtain a new access token.

At, the utility servercan report a successful cancellation and revocation of the token to the intermediary server. The intermediary server, upon notification that the subscription is cancelled and that the access token has been revoked, can at, delete records associated with that subscription ID. The intermediary servercan also provide, at, a message or notification to the user devicethat the subscription has been successfully cancelled.

At, the user devicecan optionally delete data associated with the utility usage information which is collected on the user device.

illustrates a data flowfor suspending or cancelling the subscription initiated at the utility server. At, a condition may be met where the utility serverdeems it necessary to suspend or cancel the subscription. For example, if the user cancels their utility service with the utility, then as part of the utility shut off procedures, the utility servermay cancel the subscription. In another example, if the user is more than a threshold number of days late on their payment for utility services, the utility servercan initiate a suspension of the utility usage data. These considerations are not exhaustive and the utility servermay suspend or cancel the subscription for utility usage information for other reasons.

At, if the action at the utility serveris for cancellation (rather than suspension), the access token can be revoked by the utility server, such as described above. At, the utility servermay then notify the intermediary serverof the cancellation or suspension. In some instances, the intermediary servermay mark the records associated with a suspended subscription as being subject to deletion if a resumption of the subscription is not initiated within a particular time period. At, in some instances the intermediary servermay delete all records associated with that subscription ID.