Substance computing architecture with intelligent IOT device resource discovery and opportunity allocation

Abstract

A method for a matter computing architecture with intelligent discovery and opportunity allocation of IoT device resources includes obtaining a device identifier for each of a plurality of devices within an ecosystem of a vehicle, each device identifier including a resource capability and a resource demand of the device. For each device, the method further includes verifying the device based on the obtained device identifier, and classifying the device based on resource capabilities and resource requirements of the device. The method further includes generating a device controller matrix by identifying ecosystem resource requirements for the plurality of devices, predicting ecosystem resource availability for the plurality of devices, and prioritizing resource capabilities and resource requirements for each device based on the ecosystem resource requirements and the ecosystem resource availability.

Description

Technical Field

[0001] The information provided in this disclosure is for the purpose of generally presenting the context of the disclosure. The work of the presently named inventors, to the extent it is described in this section and insofar as it may not qualify as prior art at the time of filing, is neither explicitly nor implicitly admitted as prior art to the present disclosure. Background Art

[0002] The present disclosure generally relates to a material computing architecture with intelligent discovery and opportunistic allocation of resources for Internet of Things (IoT) devices. Due to their inherent mobility, modern vehicles dynamically communicate with IoT devices, which enter and exit the vehicle's ecosystem based on the vehicle's relative location. While these IoT devices can choose to enter the vehicle's ecosystem, not all of these IoT devices can use the same communication links (i.e., communication fabric) to communicate with the vehicle. Consequently, an IoT device may not be able to see or communicate with IoT devices in a different fabric. Summary of the Invention

[0003] One aspect of the present disclosure provides a computer-implemented method for a material computing architecture with intelligent discovery and opportunistic allocation of IoT device resources. The method, when executed on data processing hardware, causes the data processing hardware to perform operations comprising obtaining a device identifier for each of a plurality of devices within a vehicle's ecosystem. Each device identifier includes a corresponding resource capability and a corresponding resource requirement for the device. For each of the plurality of devices, the operations further comprise verifying the device based on the obtained device identifier and classifying the device based on the corresponding resource capability and the corresponding resource requirement. The operations further comprise generating a device controller matrix by identifying ecosystem resource requirements of the plurality of devices in the vehicle's ecosystem based on the corresponding resource requirements of each of the plurality of devices, predicting ecosystem resource availability for the plurality of devices in the vehicle's ecosystem based on the device classification of the plurality of devices, and prioritizing the corresponding resource capability and the corresponding resource requirement of each of the plurality of devices based on the ecosystem resource requirements and the ecosystem resource availability.

[0004] Implementations of the present disclosure may include one or more of the following optional features. In some implementations, classifying each of the plurality of devices based on their respective resource capabilities and respective resource requirements further includes assigning a role to each of the plurality of devices. In these implementations, the assigned role of each of the plurality of devices may include one of a provider device, a receiver device, or a hybrid device. Here, generating the device controller matrix may further include reassigning the hybrid device as one of a provider device or a receiver device based on the ecosystem resource requirements and the ecosystem resource availability.

[0005] In some examples, classifying each of the plurality of devices based on their respective resource capabilities and respective resource requirements includes assigning roles to the devices. Here, prioritizing the respective resource capabilities and respective resource requirements of each of the plurality of devices includes identifying a first device from the plurality of devices having a respective resource capability that exceeds the respective resource requirement. In these examples, generating the device controller matrix may further include updating the device classification of the first device by reassigning the role of the first device to a provider device role and assigning the respective resource capability of the first device that exceeds the respective resource requirement of the first device to a second device having a recipient device role.

[0006] In some embodiments, classifying each of the plurality of devices based on their respective resource capabilities and respective resource requirements includes assigning roles to the devices. Here, prioritizing the respective resource capabilities and respective resource requirements of each of the plurality of devices includes identifying a first device from the plurality of devices having a respective resource requirement that exceeds the respective resource capabilities. In these examples, generating the device controller matrix may further include updating the device classification of the first device by reassigning the role of the first device to a recipient device role and assigning the respective resource capabilities of a second device having a provider device role to the first device.

[0007] In some implementations, generating the device controller matrix is further based on a device presence pattern. In some examples, a first device in the plurality of devices includes a first communication protocol, and a second device in the plurality of devices includes a second communication protocol. Here, the first device and the second device communicate via the vehicle's ecosystem.

[0008] Another aspect of the present disclosure provides a system for a material computing architecture with intelligent discovery and opportunistic allocation of IoT device resources, the system comprising data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed by the data processing hardware, cause the data processing hardware to perform operations, the operations comprising obtaining a device identifier for each of a plurality of devices within a vehicle's ecosystem. Each device identifier includes a corresponding resource capability and a corresponding resource requirement of the device. For each of the plurality of devices, the operations further comprise verifying the device based on the obtained device identifier and classifying the devices based on the corresponding resource capabilities and corresponding resource requirements of the devices. The operations further comprise generating a device controller matrix by identifying ecosystem resource requirements of the plurality of devices in the vehicle's ecosystem based on the corresponding resource requirements of each of the plurality of devices, predicting ecosystem resource availability of the plurality of devices in the vehicle's ecosystem based on the device classification of the plurality of devices, and prioritizing the corresponding resource capabilities and corresponding resource requirements of each of the plurality of devices based on the ecosystem resource requirements and the ecosystem resource availability.

[0009] This aspect may include one or more of the following optional features. In some embodiments, classifying each of the plurality of devices based on their respective resource capabilities and respective resource requirements further includes assigning a role to each of the plurality of devices. In these implementations, the assigned role of each of the plurality of devices may include one of a provider device, a recipient device, or a hybrid device. Here, generating the device controller matrix may further include reassigning the hybrid device as one of a provider device or a recipient device based on the ecosystem resource requirements and the ecosystem resource availability.

[0010] In some examples, classifying each of the plurality of devices based on their respective resource capabilities and respective resource requirements includes assigning roles to the devices. Here, prioritizing the respective resource capabilities and respective resource requirements of each of the plurality of devices includes identifying a first device from the plurality of devices having a respective resource capability that exceeds the respective resource requirement. In these examples, generating the device controller matrix may further include updating the device classification of the first device by reassigning the role of the first device to a provider device role and assigning the respective resource capability of the first device that exceeds the respective resource requirement of the first device to a second device having a recipient device role.

[0011] In some embodiments, classifying each of the plurality of devices based on their respective resource capabilities and respective resource requirements includes assigning roles to the devices. Here, prioritizing the respective resource capabilities and respective resource requirements of each of the plurality of devices includes identifying a first device from the plurality of devices having a respective resource requirement that exceeds the respective resource capabilities. In these examples, generating the device controller matrix may further include updating the device classification of the first device by reassigning the role of the first device to a recipient device role and assigning the respective resource capabilities of a second device having a provider device role to the first device.

[0012] In some implementations, generating the device controller matrix is further based on a device presence pattern. In some examples, a first device in the plurality of devices includes a first communication protocol, and a second device in the plurality of devices includes a second communication protocol. Here, the first device and the second device communicate via the vehicle's ecosystem.

[0013] The details of one or more embodiments of the present disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings described herein are for illustrative purposes only of selected configurations and are not intended to limit the scope of the present disclosure.

[0015] Figure 1 is a schematic diagram of an example system for a matter computing architecture with intelligent discovery and opportunity allocation.

[0016] Figure 2 yes Figure 1 Schematic diagram of example components of a system.

[0017] Figure 3 is a schematic diagram of an example recipient device communicating with the example recipient device through a device controller system of a vehicle.

[0018] Figure 4 is a flow diagram of an example arrangement of operations of a method for a material computing architecture with intelligent discovery and opportunity allocation.

[0019] Figure 5 is a flow diagram of an example arrangement of operations of a method for a material computing architecture with intelligent discovery and opportunity allocation.

[0020] Figure 6 is a flow diagram of an example arrangement of operations for a method of classifying devices in a computing-of-matter architecture.

[0021] Corresponding reference characters indicate corresponding parts throughout the several views of the drawings. DETAILED DESCRIPTION

[0022] Example configurations will now be described more fully with reference to the accompanying drawings. The example configurations are provided so that this disclosure will be thorough and will fully convey the scope of the disclosure to those of ordinary skill in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configurations of the present disclosure. It will be apparent to those of ordinary skill in the art that specific details need not be employed, that the example configurations may be embodied in many different forms, and that the specific details and example configurations should not be construed as limiting the scope of the present disclosure.

[0023] The terms used herein are only used to describe the purpose of specific exemplary configurations and are not intended to be limiting. As used herein, the singular articles "a", "an" and "the" may also be intended to include plural forms, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "including" and "having" are inclusive and therefore specify the presence of features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts and / or groups thereof. The method steps, processes and operations described herein should not be interpreted as necessarily requiring them to be performed in the specific order discussed or shown, unless specifically identified as an execution order. Additional or alternative steps may be adopted.

[0024] When an element or layer is referred to as being "on," "engaged to," "connected to," "attached to," or "coupled to" another element or layer, it may be directly on, directly engaged, connected, attached to, or coupled to the other element or layer, or there may be intervening elements or layers. Conversely, when an element is referred to as being "directly on," "directly engaged to," "directly connected to," "directly attached to," or "directly coupled to" another element or layer, there may be no intervening elements or layers. Other words used to describe the relationship between elements should be interpreted in a similar manner (e.g., "between" versus "directly between," "adjacent" versus "directly adjacent," etc.). As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0025] The terms "first", "second", "third" etc. may be used in this article to describe various elements, components, regions, layers and / or parts. These elements, components, regions, layers and / or parts should not be limited by these terms. These terms can only be used to distinguish one element, component, region, layer or part from another region, layer or part. Unless the context clearly indicates, terms such as "first," "second" and other numerical terms do not imply an order or sequence. Therefore, without departing from the teaching of the example configuration, the first element, component, region, layer or part discussed below may be referred to as a second element, component, region, layer or part.

[0026] In this application, including the definitions below, the term "module" may be replaced with the term "circuit". The term "module" may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field-programmable gate array (FPGA); a processor (shared, dedicated, or group) that executes code; a memory (shared, dedicated, or group) that stores code executed by the processor; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip.

[0027] The term "code" as used above may include software, firmware and / or microcode, and may refer to programs, routines, functions, classes and / or objects. The term "shared processor" includes a single processor that executes some or all code from multiple modules. The term "group processor" includes a processor that, in combination with additional processors, executes some or all code from one or more modules. The term "shared memory" encompasses a single memory that stores some or all code from multiple modules. The term "group memory" includes memory that, in combination with additional memory, stores some or all code from one or more modules. The term "memory" may be a subset of the term "computer-readable medium". The term "computer-readable medium" does not include transient electrical and electromagnetic signals propagated through the medium, and therefore may be considered to be tangible and non-transitory memory. Non-limiting examples of non-transitory memory include tangible computer-readable media, including non-volatile memory, magnetic memory, and optical memory.

[0028] The apparatus and methods described herein may be implemented in part or in whole by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer programs may also include and / or rely on stored data.

[0029] A software application (i.e., a software resource) may refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0030] Non-transitory memory can be a physical device used to temporarily or permanently store programs (e.g., instruction sequences) or data (e.g., program state information) for use by a computing device. Non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0031] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., magnetic disks, optical disks, memory, programmable logic devices (PLDs)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0032] Various implementations of the systems and techniques described herein can be realized in digital electronic and / or optical circuitry, integrated circuits, specially designed ASICs (application-specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs executable and / or interpretable on a programmable system comprising at least one programmable processor, which can be special purpose or general purpose, coupled to receive data and instructions from and send data and instructions to a storage system, at least one input device, and at least one output device.

[0033] The processes and logic flows described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware) that execute one or more computer programs to perform functions by operating on input data and generating outputs. The processes and logic flows can also be performed by dedicated logic circuits (e.g., FPGAs (field programmable gate arrays) or ASICs (application-specific integrated circuits)). As an example, processors suitable for executing computer programs include both general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Typically, a processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or be operably coupled to receive data from it or transmit data to it or both. However, a computer need not have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and storage devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0034] To provide for interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), an LCD (liquid crystal display) monitor, or a touch screen) for displaying information to the user and, optionally, a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. Additionally, a computer may interact with a user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0035] Figure 1An example system 100 is shown that includes a device controller system 200 that implements a service provider allocation model 230. The device controller system 200 includes a vehicle 10 that communicates with a plurality of Internet of Things (IoT) devices 20, 20a-n (also referred to as devices 20) within an ecosystem 30 of the vehicle 10 via a vehicle network 16. The ecosystem 30 may include any device 20 within an environment 32 (i.e., network range 32) of the vehicle network 16. The vehicle network 16 may include a wireless local area network (WLAN) that facilitates communication and interoperability between the vehicle 10 and the devices 20 within the environment 32 of the vehicle 10. In the example shown, the devices 20 within the environment 30 have all opted into the ecosystem 30 of the vehicle 10 and are therefore communicating with the vehicle 10 via the device controller system 200. Specifically, the devices 20 are located around the vehicle 10 and include an electric vehicle (EV) charging station 20a, a visitor vehicle 20b, a cellular device 20c, a personal computer 20d, a tablet computer 20e, a television (TV) 20f, and a camera system 20g. The device controller system 200 can communicate with each device 20 in the ecosystem 30 via wireless or wired communication technologies and / or protocols. Thus, the vehicle network 16 may include Wireless Fidelity (WiFi) (e.g., IEEE 802.11), low-rate wireless personal area network (e.g., IEEE 802.15.4), Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, Long Term Evolution (LTE), 5G, Digital Subscriber Line (DSL), Bluetooth, and the like. Near Field Communication (NFC) or any other wireless standard or Ethernet (e.g., IEEE 802.3). The vehicle 10 may additionally include one or more access points (APs) (not shown) configured to facilitate wireless communication between the vehicle 10 and one or more of the devices 20, 20a-g.

[0036] Additionally, each device 20 may communicate with other devices 20 within the same communication structure / cluster as the device 20. For example, Figure 1 Devices 20c-20g are shown as being part of a user's premises, where devices 20c-20g can communicate with each other via a first communication structure (e.g., a home area network (HAN)), while devices 20a, 20b may not be part of the first communication structure but may communicate with vehicle 10 via a second communication structure different from the first communication structure. Therefore, devices 20b-20g can only communicate with devices 20a, 20b via vehicle 10 (i.e., executing device controller system 200).

[0037] In the example shown, the device controller system 200 is implemented within the vehicle 10. However, the device controller system 200 can be implemented on other computing devices (e.g., computing devices that communicate with the vehicle 10), such as, but not limited to, smart phones, tablets, smart displays, desktops / laptops, smart watches, smart appliances, or smart glasses / headphones. The vehicle 10 includes data processing hardware 12 and memory hardware 14 that stores instructions that, when executed on the data processing hardware 12, cause the data processing hardware 14 to perform operations. In addition to the vehicle network 16, the vehicle 10 communicates with a remote system 60 via a network 40. The remote system 60 (e.g., a server, a cloud computing environment) also includes data processing hardware 62 and memory hardware 64 that stores instructions that, when executed on the data processing hardware 62, cause the data processing hardware 62 to perform operations. In some examples, execution of the device controller system 200 is shared across the vehicle 10 and the remote system 60. As described below with reference to Figure 2 and Figure 3 As described in greater detail, the device controller system 200 executing on the vehicle 10 and / or remote system 60 executes a verification module 210, a classifier module 220, and a service provider allocation model 230, and is configured to intelligently discover devices 20 that dynamically join and leave the vehicle network 16, wherein the device controller system 200 opportunistically allocates resources 26, 28 of the devices 20 based on predictions of near-term resource availability to reduce costs and improve efficiency, thereby increasing utilization of the devices 20. Notably, because the device controller system 200 of the vehicle 10 is communication agnostic (i.e., it communicates via a public application programming interface (API)), it operates to integrate / facilitate communications between devices 20 that would otherwise be unaware of the devices 20 outside of their own communication structure.

[0038] The device controller system 200 can be implemented on any computing device capable of communicating with the device 20. Although the device controller system 200 is included in the vehicle 10 in the illustrated example, the device controller system 200 can also be included in, but is not limited to, a smartphone, smartwatch, laptop, desktop computer, or smart display. When the device 20 selects to enter the ecosystem 30 (e.g., by the user of the device 20 during the communication association process with the vehicle 10), the device 20 can thereafter be discovered by the device controller system 200 of the vehicle 10 at any time when the device 20 is within range of the vehicle 10 (e.g., the environment 32).

[0039] In some embodiments, the vehicle 10 executes a device controller system 200 (including a service provider allocation model 230) that initiates communication with each device 20 so that each device 20 in the plurality of devices 20 (i.e., a device 20 having the role 29 of a provider device 29D) can be controlled by the device controller system 200 to perform available actions (i.e., via resource capabilities 26) requested by a different device 20 (i.e., a device 20 having the role 29 of a recipient device 29R). In the illustrated example, the device controller system 200 obtains a device identifier 22 for each of the plurality of devices 20 within the ecosystem 30 of the vehicle 10. In some embodiments, the vehicle 10 intelligently discovers the device 20 upon entry into the ecosystem 30 of the vehicle 10 and generates a request for the device identifier 22, which prompts the device 20 to share its device identifier 22. In other implementations, when the device 20 enters the ecosystem 30, the device 20 may advertise its intent to join the ecosystem 30, thereby prompting the vehicle 10 to request the device identifier 22 of the device 20.

[0040] Each device identifier 22 may include a corresponding device identity (ID) 24 that includes a unique identifier for the device 20, corresponding resource capabilities 26 for the device 20, and corresponding resource requirements 28 for the device 20. The device identifier 22 may include a fabric certificate that conveys the device ID 24, corresponding resource capabilities 26, and corresponding resource requirements 28 of the device 20, wherein the device controller system 200 (via a public API) understands / translates the fabric certificate to integrate the device 20 with other devices 20 within the ecosystem 30. The resource capabilities 26 include the inherent resource capabilities of the device 20, such as the energy capability / capacity of the device 20, the available storage of the device 20, the computational cost of the device 20, the processing performance of the device 20 (e.g., MIPS), any communication fabric of the device 20, an estimate of the amount of time the device 20 will be underutilized (e.g., how long the device 20 will have available resource capabilities 26), an estimate of the amount of time the device 20 will be in the ecosystem 30 of the vehicle 10, and standard services, such as displays, cameras, and sensors operated by the device 20. Resource requirements 28 may include the dynamic usage of device 20 (e.g., its baseline operation), as well as any capacity requirements that device 20 may have that exceed the resource capabilities 26 of device 20. For example, a device 20 that does not include a graphical user interface may have a resource requirement 28 for a graphical user interface when displaying information to a user of device 20.

[0041] refer to Figure 1 and Figure 2, the device controller system 200 includes a verification module 210, a classifier module 220, a service provider allocation model 230, and a device data store 240. The verification module 210 is configured to receive the obtained device identifier 22 and verify the device 20 based on the device identifier 22 (e.g., device ID 24). For example, the vehicle 10 can verify the device 20 by checking the device ID 24 against a list of known devices 20 that have selected to enter the ecosystem 30 of the device controller system 200. If the verification module 210 determines that the device 20 is not a valid device, it can block the device 20 from the ecosystem 30 of the vehicle 10.

[0042] If the verification module 210 verifies the device 20, the classification module 220 is configured to classify the device 20 based on its device ID 24, resource capabilities 24, and resource requirements 28, and output a device classification 222 for the plurality of devices 20. For example, the classification module 220 may assign a role 29 to each of the plurality of devices 20. The roles 29 assigned by the classification module include a provider device 20D, a recipient device 20R, and a hybrid device 20H. The provider device 20D may be a device 20 that includes resource capabilities 26 that exceed the resource requirements 28 of the provider device 20D. Conversely, the recipient device 20R may be a device 20 that includes resource requirements 28 that exceed the resource capabilities 26 of the recipient device 20R. In other words, the provider device 20D may be a currently underutilized device 20, while the recipient device 20R may be a device 20 that currently lacks the resource capabilities 26 required for optimal operation. Notably, the device roles 29 may be assigned based on the specific services performed by the device 20. For example, if device 20 is a smart thermostat, it can function as a provider device 20D for weather application information, but not as a provider device 20D for imaging. Conversely, if the smart thermostat requires imaging services, it can be assigned the role 29 of a receiver device 20R for imaging services. A hybrid device 20H can be a device 20 that can function as either a provider device 20D or a receiver device 20R, depending on the best utilization of capabilities 26 and needs 28 within the ecosystem 30 at any given moment.

[0043] Continue to refer Figure 2After the classifier module 220 outputs the device classification 222 for the plurality of devices 20, the service provider allocation model 230 can receive the device classification 222 including each device identifier 22 having a corresponding resource capability 26 and a corresponding resource requirement 28 and generate a device controller matrix 232. Specifically, the service provider allocation model 230 predicts the ecosystem resource requirements 224 for the plurality of devices 20 in the ecosystem 30 of the vehicle 10 based on the corresponding resource requirements 28 for each of the plurality of devices 20. Here, the service provider allocation model 230 predicts the ecosystem resource requirements 224 based on the existing resource requirements 28 of the devices 20.

[0044] The service provider allocation model 230 also predicts ecosystem resource availability 226 for a plurality of devices 20 in the ecosystem 30 of the vehicle 10 based on the device classification 222 and the corresponding resource capabilities 26 of each device 20. The ecosystem resource availability 226 indicates an estimate of the near-term (e.g., one second, five seconds, five minutes, etc.) resource availability of the devices 20 within the ecosystem 30 of the vehicle 10 and is based on historical data 242 regarding the dynamic usage of each device 20 and the behavior of the device 20, as conveyed in the device identifier 22. For example, the service provider allocation model 230 accesses a device data store 240 that records / stores historical data 242, including historically received device identifiers 22, including device IDs 24, resource capabilities 26, and resource requirements 28, the device classification 222, and ecosystem resource requirements 224 and ecosystem resource availability 226 for a previous state of the ecosystem 30. Additionally, a previous device controller matrix 232 may be stored in the device data store 240. The historical records of the device data store 240 may be stored on the memory hardware 14 of the vehicle 10 and / or the memory hardware 64 of the remote server 60. Here, when predicting the ecosystem resource availability 226 for a plurality of devices 20, the service provider allocation model 230 may estimate, based on the historical data 242 stored in the device data store 240, the average amount of time that the device 20 is within the ecosystem 30, the frequency with which the device 20 is within the ecosystem 30, the device presence pattern indicating the frequency and time with which the device 20 is within the ecosystem 30, and / or the pattern of the corresponding capabilities 26 of the device 20 while within the ecosystem 30. For example, the device data store 240 may include historical data indicating the presence pattern of a visitor vehicle 20b, which enters the ecosystem 30 for four (4) hours each weekday (i.e., Monday through Friday). In this example, the ecosystem resource availability 226 predicted by the service provider allocation model 230 may include the corresponding capabilities 26b of the visitor vehicle 20b as the predicted available resources for the other devices 20 in the ecosystem 30 of the vehicle 10. The service provider allocation model 230 may prioritize the corresponding capabilities 26b of the visitor vehicle 20b based on the confidence level of the presence pattern of the visitor vehicle 20b.

[0045] Using the ecosystem resource demands 224 and the ecosystem resource availability 226, the service provider allocation model 230 then prioritizes the corresponding resource capabilities 26 and corresponding resource demands 28 of each of the plurality of devices 20 to generate a device controller matrix 232. In some implementations, the service provider allocation model 230 only updates the device controller matrix 232 from the previous time step when the ecosystem resource demands 224 meet or exceed a minimum threshold for resource usage in the vehicle 10's ecosystem 30 (e.g., the ecosystem resource capacity 226 or 90% of the ecosystem resource capacity 226). In other words, when the ecosystem resource demands 224 are less than the ecosystem resource availability 226, the service provider allocation model 230 may maintain the current device controller matrix 232 and continue to monitor the ecosystem resource demands 224 until the ecosystem resource demands equal or exceed the minimum threshold. Furthermore, the service provider allocation model 230 may generate one or more resource allocations 234 for each device 20 assigned to provide resources (i.e., the provider device 20D) and transmit the resource allocations 234 to the corresponding devices 20 in the environment. In prioritizing the corresponding resource capabilities 26 and the corresponding resource demands 28, the service provider allocation model 230 can optimize the mix of device roles 29 based on the dynamically changing needs of the ecosystem 30 of the vehicle 10 (i.e., as devices 20 join and leave). For example, the service provider allocation model 230 can reallocate the role 29 of the hybrid device 20H to one of the role of the provider device 20D and the role of the recipient device 20R based on one of the ecosystem resource demands 224 and the ecosystem resource availability 226. Figure 2 As shown, although the device classification 222 initially includes the device ID 24 of vhcl_34 (e.g., visitor vehicle 20b) and the device ID 24 of home_comp assigned to the role of hybrid device 20H, the service provider assignment model 230 reassigns the role 29 to the role 29 of the provider device 20D when generating the device controller matrix 232.

[0046] In some embodiments, after the classifier module 220 has assigned a role 29 to each device 20, the service provider allocation model 230 may modify / update the assigned role 29 when the service provider allocation model 230 prioritizes the corresponding resource capabilities 26 and the corresponding resource demands 28 of each device 20 in the plurality of devices 20. For example, when prioritizing the corresponding resource capabilities 26 and the corresponding resource demands 28 of each device 20, the service provider allocation model 230 may identify a first device 20 in the plurality of devices 20 that has a corresponding resource capability 26 that exceeds the corresponding resource demands 24 of the device 20. For example, the first device 20 may be a visitor vehicle 20b that is parked and unused and, therefore, is not currently utilizing its own resource capabilities 26. Here, when generating the device controller matrix 232, the service provider allocation model 230 updates the device classification 222 of the visitor vehicle 20b by reassigning the role 29 of the visitor vehicle 20b to the role 29 of the provider device 20D. Thereafter, the service provider allocation model 230 may send a resource assignment 234 to the visitor vehicle 20 b to execute using its underutilized resource capacity 26 .

[0047] Conversely, when prioritizing the corresponding resource capabilities 26 and the corresponding resource requirements 28 of each device 20, the service provider allocation model 230 may identify a second device 20 among the plurality of devices 20 that has a corresponding resource requirement 28 that exceeds the corresponding resource capabilities 26 of the second device 20. For example, the second device 20 may be installed in Figure 1 20g is located on the exterior surface of the residence, but due to its location, it cannot capture image data outside its field of view. However, in the event that camera system 20g requires an additional field of view (i.e., for the security of the residence), it can benefit from any imaging device within ecosystem 30. Here, when generating device controller matrix 232, service provider allocation model 230 updates device classification 222 of camera system 20g by reassigning role 29 of camera system 20g to role 29 of recipient device 20R. Thereafter, service provider allocation model 230 can send resource assignments 234 to devices 20 assigned provider roles 20D within ecosystem 30 (e.g., visitor vehicles 20b with imaging resources), which provider roles 20D are capable of meeting resource requirements 28g of camera system 20g.

[0048] refer to Figure 3, shows a system 300 including a vehicle 10, with an EV charger 20a and a tablet computer 20e within the vehicle 10's ecosystem 30. Here, tablet computer 20e is located within vehicle 10, and EV charger 20a does not have a screen for displaying information. When device controller system 200 obtains device identifier 22 of EV charger 20a (e.g., when EV charger 20a enters range of vehicle network 16), device controller system 200 can classify EV charger 20a as a receiving device 20R with respect to its ability to display data. In other words, because EV charger 20a does not include a screen, device controller system 200 can identify and verify EV charger 20a as a device that can benefit from available resource capabilities 26 for displaying data from available devices 20 with screens within the vehicle 10's ecosystem 30. Here, when service provider allocation model 230 generates device controller matrix 232, it can identify that tablet computer 20e is not currently utilizing its corresponding display data capabilities 26. In other words, tablet computer 20e's display data capabilities 26 are currently underutilized within ecosystem 30. The vehicle 10 may then be assigned a tablet computer 20 e to display data from the EV charger 20 a so that passengers of the vehicle 10 can be informed of the vehicle's charging status.

[0049] Figure 4 Flowchart including an example arrangement of operations of a method 400 for a material computing architecture with intelligent discovery and opportunistic allocation of IoT device resources. Figure 1 The data processing hardware 12, 62) can execute data stored in the memory hardware (e.g., Figure 1 In an example arrangement of instructions on the memory hardware 14, 64 of the vehicle 10 to perform the operations of the method 400. At operation 402, the method 400 includes obtaining a device identifier 22 for each of a plurality of devices 20 within the ecosystem 30 of the vehicle 10. Each device identifier 22 includes a corresponding resource capability 26 and a corresponding resource requirement 28 of the device 20.

[0050] For each device 20 in the plurality of devices 20, method 400 further includes, at operation 404, verifying the device 20 based on the obtained device identifier 22 and classifying the device 20 based on the respective resource capabilities 26 and respective resource requirements 28 of the device 20. At operation 406, method 400 further includes generating a device controller matrix 232 by identifying the ecosystem resource requirements 224 of the plurality of devices 20 in the ecosystem 30 of the vehicle 10 based on the respective resource requirements 28 of each of the plurality of devices 20. Method 400 further includes, at operation 408, predicting the ecosystem resource availability 226 of the plurality of devices 20 in the ecosystem 30 of the vehicle 10 based on the device classification 222 of the plurality of devices 20. Method 400 further includes, at operation 410, prioritizing the respective resource capabilities 26 and respective resource requirements 28 of each of the plurality of devices 20 in the plurality of devices 20 based on the ecosystem resource requirements 224 and the ecosystem resource availability 226.

[0051] Figure 5 A flow chart including an example arrangement of operations of a method 500 for a device controller 200 to intelligently discover devices 20 within a vehicle's ecosystem 30 and opportunistically allocate unused or underutilized capabilities 26 of the devices 20. Data processing hardware (e.g., Figure 1 The data processing hardware 12, 62) can execute data stored in the memory hardware (e.g., Figure 1 64) to perform an example arrangement of operations for method 500. At operation 502, method 500 includes device 20 announcing its intention to join the ecosystem 30 of vehicle 10. Device 20 may announce its intention by opting into the ecosystem 30 of vehicle 10. For example, when device 20 is within communication range of vehicle 10 (e.g., within range of vehicle network 16), it may prompt a user of device 20 to opt into the ecosystem 30 of vehicle 10. In other examples, device 20 may automatically announce its intention to join the ecosystem 30 when it is within communication range of vehicle 10.

[0052] At operation 504, method 500 also includes vehicle 10 requesting a device identifier 22 from device 20 (e.g., via device controller system 200). For example, device identifier 22 may include communication credentials. At operation 506, operation 500 also includes device 20 sending device identifier 22. Here, device identifier 22 includes resource capabilities 26 (e.g., computing capabilities) and resource requirements 28 (e.g., computing requirements) of device 20. Device identifier 22 may also include device ID 24 of device 20. At each time step, method 500 also includes generating device controller matrix 232 at operation 508. Here, at operation 510, service provider allocation model 230 of device controller system 200 determines whether identified ecosystem resource demand 224 exceeds predicted near-term ecosystem resources 226. In other words, service provider allocation model 230 determines whether identified ecosystem resource demand 224 is less than a minimum threshold for resource usage of ecosystem 30, thereby eliminating the need for further optimization. If the ecosystem resource demand 224 does not exceed the predicted near-term ecosystem resources 226, the method 500 proceeds to operation 512, where the service provider allocation model 230 maintains the device 20 in an active state in the device controller matrix 232 and continues to monitor the ecosystem resource availability 224. If the ecosystem resource demand 224 does exceed the predicted near-term ecosystem resources 226, the method 500 proceeds from operation 510 to operation 514, where the service provider allocation model 230 allocates the resource capacity 26 of the device 20 in the device controller matrix 232 to the resource demand 28 of another device 20 also in the ecosystem 30 of the vehicle 10.

[0053] Figure 6 A flow chart including an example arrangement of operations for a method 600 for classifying a device 20 in a matter computing architecture by updating the device classification 222 in the device controller matrix 232. Data processing hardware (e.g., Figure 1 The data processing hardware 12, 62) can execute data stored in the memory hardware (e.g., Figure 1 64) to perform an example arrangement of operations of method 600. At operation 602, method 600 includes authenticating device 20 using authentication module 210. At operation 604, method 600 also includes categorizing device 20 based on its resource capabilities 26 and resource requirements 28 using classification module 220.

[0054] At operation 606, method 600 includes determining whether the device 20 is assigned the role 29 of the provider device 20D. If the device 20 is not assigned the role 29 of the provider device 20D, method 600 proceeds to operation 608, which assigns the device 20 in the device controller matrix 232 to the role 29 of the recipient device 20R. If the device 20 is assigned the role 29 of the provider device 20D, method 600 proceeds to operation 610, which includes determining whether the resource capabilities 26 of the device 20 exceed the resource requirements 28 of the device 20. If the resource capabilities 26 of the device 20 do not exceed (i.e., are equal to or less than) the resource requirements 28 of the device 20 at operation 610, method 600 proceeds to operation 612, which determines whether the device 20 requires additional resource capabilities 26. If the device 20 requires additional resource capabilities 26, the method 600 returns to operation 608 and the device 20 in the device controller matrix 232 is assigned (ie, reassigned) to the role 29 of the recipient device 20R.

[0055] At operation 612, if the device 20 does not require additional resource capabilities 26, the method 600 proceeds to operation 614, where the service provider allocation model 230 can update the device controller matrix 232 to include an idle state. If, at operation 610, the resource capabilities 26 of the device 20 exceed the resource requirements 28 of the device 20 (i.e., the device 20 includes unused or underutilized resource capabilities 26), the method 600 proceeds to operation 616, which includes prioritizing the resource capabilities 26 and resource requirements 28 of the device 20 to generate the device controller matrix 232, and generating one or more resource allocations 234 that allocate the corresponding resource requirements 28 of another device 20 to the resource capabilities 28 of the device 20.

[0056] A number of embodiments have been described. However, it will be appreciated that various modifications can be made without departing from the spirit and scope of this disclosure. Accordingly, other embodiments are within the scope of the following claims.

[0057] The foregoing description is provided for the purpose of illustration and description. It is not intended to be exhaustive or to limit the present disclosure. Individual elements or features of a particular configuration are generally not limited to that particular configuration, but are interchangeable where applicable and can be used in a selected configuration, even if not specifically shown or described. They may also vary in many ways. Such variations should not be considered as departing from the present disclosure, and all such modifications are intended to be included within the scope of the present disclosure.

Claims

1. A computer-implemented method that, when executed on data processing hardware, causes the data processing hardware to perform operations comprising: obtaining a device identifier for each of a plurality of devices within an ecosystem of the vehicle, each device identifier including a corresponding resource capability and a corresponding resource requirement of the device; For each device in the plurality of devices: authenticating the device based on the obtained device identifier; as well as classifying the devices based on the respective resource capabilities and the respective resource requirements of the devices; as well as Generate the device controller matrix by following these steps: identifying ecosystem resource requirements of the plurality of devices in an ecosystem of the vehicle based on respective resource requirements of each of the plurality of devices; predicting ecosystem resource availability of the plurality of devices in the ecosystem of the vehicle based on the device classification of the plurality of devices; as well as The respective resource capabilities and the respective resource demands of each of the plurality of devices are prioritized based on the ecosystem resource demands and the ecosystem resource availability.

2. The method according to claim 1, wherein Categorizing each of the plurality of devices based on the respective resource capabilities and the respective resource requirements of the device further includes assigning a role to each of the plurality of devices.

3. The method according to claim 2, wherein: The assigned role of each of the plurality of devices includes one of a provider device, a recipient device, or a hybrid device. 4 . The method of claim 3 , wherein generating the device controller matrix further comprises reallocating hybrid devices as one of a provider device or a receiver device based on the ecosystem resource demand and the ecosystem resource availability.

5. The method according to claim 1, wherein Categorizing each of the plurality of devices based on the respective resource capabilities and the respective resource requirements of the device includes assigning a role to the device; as well as The prioritizing the corresponding resource capabilities and the corresponding resource requirements of each of the plurality of devices includes identifying a first device of the plurality of devices having a corresponding resource capability that exceeds a corresponding resource requirement.

6. The method according to claim 5, wherein: Generating the device controller matrix further includes: updating the device classification of the first device by reassigning the role of the first device to a provider device role; and The corresponding resource capabilities of the first device that exceed the corresponding resource requirements of the first device are assigned to a second device having a recipient device role.

7. The method according to claim 1, wherein Categorizing each of the plurality of devices based on the respective resource capabilities and the respective resource requirements of the device includes assigning a role to the device; as well as Wherein prioritizing the respective resource capabilities and the respective resource requirements of each of the plurality of devices comprises identifying a first device of the plurality of devices having a respective resource requirement that exceeds a respective resource capability.

8. The method according to claim 7, wherein: Generating the device controller matrix further includes: updating the device classification of the first device by reassigning the role of the first device to a recipient device role; and The corresponding resource capabilities of the second device having the provider device role are allocated to the first device.

9. The method according to claim 1, wherein Generating the device controller matrix is also based on a device presence pattern.

10. The method according to claim 1, wherein A first device among the plurality of devices includes a first communication protocol, and a second device among the plurality of devices includes a second communication protocol, the first device and the second device communicating through an ecosystem of the vehicle.

Images