Fujitsu Corporation

Ulrich Herberg

Daisuke Mashima

Jorjeta Gueorguieva Jetcheva

Wei-Peng Chen

Alvaro A Cardenas

Mohammad-Mahdi Moazzami

Alvaro Cardenas

A method may include receiving peer data describing a set of peer clients associated with a demand response application server and describing how the peer clients communicate with one another. The peer data may be configured so that a subset of the peer clients directly communicate with the demand response application server and the demand response application server does not directly communicate with each of the peer clients. The method may also include receiving announcement data describing an event specified by the demand response application server and determining event response data responsive to the announcement data. The method may also include identifying, from the set of peer clients specified by the demand response application server, a set of recipient peer clients to receive the event response data.

Demand response event dissemination system and method

A method of residential or small and medium business (SMB) demand response (DR) coordination may include receiving a DR event notification from a DR server. The DR event notification may include DR event information pertaining to a DR event and curtailment information. The method may also include communicating a notification acknowledgement to the DR server. The notification acknowledgement may indicate reception of the DR event notification. The method may include displaying a curtailment request pertaining to the DR event. The curtailment request may be based on the curtailment information included in the DR event notification and may include some portion of the DR event information. The method may also include receiving a user input including a DR event participation confirmation or a DR event participation refusal. The method may further include communicating a participation signal representative of at least a portion of the user input to the DR server.

Residential and small and medium business demand response

A method includes receiving a driver model for a device. The driver model includes a list of variables associated with the device and one or more characteristics of the variables. The method includes determining whether the driver model is format-compliant and validating syntax of the driver model based at least partially on a driver template that is accessible to a third party. In response to the driver model being format-compliant and the syntax being valid, the method includes generating a verified file that is representative of the driver model. The verified file is formatted to dynamically load into a device application module during operation and to dynamically support the device. The method includes communicating the verified file to a user apparatus and adding an integrity check value thereto. In response to the driver model being format-noncompliant or the syntax being invalid, the method includes communicating an error message.

Dynamic device drivers

A method including generating a mapping in response to an enrollment message received from a customer device. The enrollment message includes a device identification number (device ID) of the customer device. The mapping includes a one-time password (OTP) encrypted using the device ID. The method includes generating a quick response (QR) code including a uniform resource locator (URL), a provider certificate (CRT), and certificate signing request (CSR) content. The method includes receiving a confirmation message at a website identified by the URL. The confirmation message includes a generated public key, a CSR, and a decrypted OTP. The method includes verifying the decrypted OTP against the mapping and communicating one or more application configuration settings. The method includes securely communicating information using the one or more application configuration settings, a provider public key, a provider private key, the generated public key, and a generated private key.

Device configuration for secure communication

A method may include receiving data and first path-metadata. The first path-metadata may include a first entity identifier. The first entity identifier may be associated with a first receiving entity that receives the data and the first path-metadata from an originating entity. The first path-metadata may also include a first digital signature associated with the originating entity. The method may further include receiving second path-metadata that may include the first path-metadata and a second entity identifier associated with a second receiving entity. The second path-metadata may also include a second digital signature associated with the first receiving entity. The method may additionally include verifying that the data was communicated by the originating entity to the first receiving entity and from the first receiving entity to the second receiving entity based on the first path-metadata, the second path-metadata, the first digital signature, and the second digital signature.

Data distribution path verification

According to an aspect of an embodiment, a method of managing packets in a communication network including multiple communication nodes is described. The method may include receiving a packet including a packet header. The packet header may include a packet identifier uniquely identifying the packet. The method may also include determining a packet type of the packet received by a first communication node based on the packet identifier. The method may also include dropping the packet when the packet is determined to be a duplicate packet or routing the packet to a neighbor communication node in a manner that prevents the packet from being caught in a loop when the packet is determined to be a returned packet or a new packet.

Growing community of inventors

Sunnyvale, CA, United States of America

Ulrich Herberg