Patent ID: 12192371

DETAILED DESCRIPTION

The exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings. The exemplary embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete and will fully convey the exemplary embodiments to those of ordinary skill in the art. Moreover, all statements herein reciting embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating the exemplary embodiments. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular named manufacturer.

As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes,” “comprises,” “including,” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include wirelessly connected or coupled. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device without departing from the teachings of the disclosure.

FIGS.1-9are simplified illustrations of predictive modeling, according to exemplary embodiments. While exemplary embodiments may be applied to any social, financial, or technical purpose, most readers are thought familiar with a learning model20. The learning model20is typically a software algorithm that uses electronic data22to make some suggestion24or prediction26. For example, the reader is likely familiar with a mapping software application28executed by a mobile device30(such as a smartphone32). The mapping software application28(such as GOOGLE® MAPS® or APPLE® MAPS®) generally suggests a route to a destination. That is, the mapping software application28obtains the electronic data22(such as a current location) and determines a road or route to a destination. The mapping software application28may even use historical data34(such as repeated travels, destinations, and other behavior) to learn habitual activity36and to predict future activity38. The mapping software application28, in plain words, applies artificial intelligence (“AI”)40to the electronic data22to learn a user's travel patterns, to suggest travel routes, and to predict the user's future location and movements.

FIG.2illustrates federated learning. Here the learning model20may be improved based on usage reported by many different mobile devices30. While the number of mobile devices may be hundreds, thousands, or even millions,FIG.2simply illustrates four (4) mobile devices30a-d. That is, all the mobile devices30a-d(again illustrated as smartphones32a-d) execute the learning model20. Each smartphone32a-drandomly, periodically, or on command sends a local update50a-dvia a communications network52to a server54. The local update50a-dmay merely summarize a local change56a-dto the learning model20. The local change56a-dmay be based on the raw electronic data22a-dgathered by, or processed by, the learning model20. The local update50a-dmay thus describe a local, focused, micro-report generated by the learning model20. The local update50a-dmay be a file that includes or specifies an alphanumeric device identifier58a-dthat uniquely identifies the corresponding mobile device30a-d, but otherwise the local update50a-dmay be anonymous for privacy concerns. Regardless, the server54may use the local updates50a-dto improve the learning model20. Indeed, the server54may aggregate the local updates50a-dto generate a learning modification60to the learning model20. The learning modification60is generally a software change that improves a performance criterion (e.g., cost, performance, timing). The server54may then download a modified learning model62that implements the learning modification60based on actual usage reported by the mobile devices30a-d. This recursive or feedback process allows the mobile devices30a-dto collaboratively learn and improve the shared learning model20.

FIG.3illustrates a blockchain70. Exemplary embodiments may use blockchain technology as documentary evidence72of the learning model20. That is, exemplary embodiments may record the electronic data22, the local update50, and/or the learning modification60as a record in the blockchain70. As the reader may understand, the blockchain70is generally a digital ledger in which data and other transactions are chronologically and/or publically recorded. The blockchain70is most commonly used in decentralized cryptocurrencies (such as Bitcoin). Exemplary embodiments, however, may adapt the blockchain70to artificial learning environments. The blockchain70may be used to prove custody of the electronic data22used by, and/or changes made to, the learning model20. Regardless, the server54may integrate the electronic data22, the local update50, and/or the learning modification60into the blockchain70for distribution or publication. The device identifier58may also be incorporated to distinguish different data records generated by different devices. While the server54may send the blockchain70to any destination address,FIG.3illustrates one or more trusted peer devices74. The server54may distribute the blockchain70to an Internet protocol address associated with any of the trusted peer devices74.

FIG.4illustrates hashing. Here exemplary embodiments may apply a hashing algorithm76to generate one or more hash values78. Exemplary embodiments may thus integrate the hash value(s)78into the blockchain70. For example, the server54may call or invoke an electronic representation of the hashing algorithm76to act on the data or information representing the electronic data22, the local update50, and/or the learning modification60. The hashing algorithm76generates the cryptographic hash values78(sometimes termed digital keys or signatures), which may then be integrated into the blockchain70. The blockchain70may thus publish or distribute the cryptographic hash values78to the trusted peer devices74.

Exemplary embodiments thus present elegant reproducibility tools. Exemplary embodiments may use blockchain technology to reproduce any changes made to the learning model20. The blockchain70may contain data records that document the raw electronic data22used by the learning model20. The blockchain70may additionally or alternatively contain data records that document the local update(s)50used to improve the learning model20. The blockchain70may additionally or alternatively contain data records that document the learning modification60implemented in response to the raw electronic data22and/or the local update(s)50. The blockchain70may additionally or alternatively contain the cryptographic hash values78representing the electronic data22, the local update50, and/or the learning modification60. Because the blockchain70contains this documentary evidence72, any recipient of the blockchain70may inspect the blockchain70(perhaps according to the device identifier58) and chronologically reproduce any data and/or changes implemented during federated learning.

FIG.5illustrates a general scheme of reproducibility. The learning model20may use the raw electronic data22(perhaps stored by the mobile device30) to generate a result80(such as the suggestion24, the prediction26, and/or the local update50illustrated inFIG.1). The learning model20may then report at least a portion of the result80to the server54. The server54may use the result80to generate the learning modification60that improves or otherwise changes the learning model20. The server54may then publish the result80and/or the learning modification60via the blockchain70to any destination device82. The blockchain70thus serves as the documentary evidence72for any changes or modifications to the learning model20. Exemplary embodiments may additionally hash the result80and/or the learning modification60(using the hashing algorithm76) and distribute the cryptographic hash value(s)78via the blockchain70as a further security measure. Any recipient of the blockchain70may thus reproduce the result80and/or the learning modification60.

Exemplary embodiments may be applied to any software application and to any objective. This disclosure mainly discusses the learning model20as the mapping software application28, as many readers have used mapping services (such as GOOGLE® MAPS® and APPLE® MAPS®). However, exemplary embodiments are applicable to any learning and/or predictive service, such as dating apps, autonomous driving software, energy consumption software (such as learning HVAC thermostats and other home automation services), predictive food/dinner software, social networking software, and any other software using the artificial intelligence40.

Exemplary embodiments help validate software developers. As the artificial intelligence40(or “machine learning”) is applied to more and more real world situations and services, the inventors foresee that software developers will have to thoroughly document their efforts. For example, as self-driving cars add users and accrue mileage, accidents will occur and liability may be at issue. Developers of autonomous driving software (e.g., the learning model20) may have to reproduce the result80and perhaps prove that the learning model20could not have caused a vehicular accident. Similarly, developers of mapping services may have to prove that their software is not liable for accidents, muggings, and other crimes along a suggested route. Developers of dating apps and other social services may have to prove that their software is not liable for personal mismatches, poor recommendations, or crimes committed during social suggestions. Should a learning thermostat overheat a room (perhaps causing death of an occupant or pet), the developer may have to prove that the learning model20could not have caused injury. Because exemplary embodiments provide the documentary evidence72of the developer's efforts, the developer need only retrieve the historical records integrated into the blockchain70.

Exemplary embodiments also help prevent fraud. As the artificial intelligence40grows in usage, unscrupulous activity may also grow. Rogue entities, in other words, may try to hack the electronic data22, and/or the learning model20, to cause harm or injury. Exemplary embodiments thus implement protections against fraudulent efforts. The blockchain70allows a software developer to document the result80generated by the learning model20, perhaps in near real time. The blockchain70documents a current state or version of the learning model20, any changes to the learning model20, and/or any of the electronic data22used or acted on by the learning model20. The software developer may thus retrieve any historical records integrated into the blockchain70to prove the learning model20could not have resulted in damage or injury. In other words, the raw electronic data22, the local update50, and/or the learning modification60could not have caused harm to person or to property. The blockchain70may thus provide the documentary evidence72of custody/possession of an original, unaltered version of the electronic data22. The blockchain70may also provide the documentary evidence72that the smartphone32generated the original, unaltered version of the electronic data22(and not some other, different, or alleged device). Moreover, the blockchain70may also provide the documentary evidence72that none of the electronic data22is missing.

FIG.6illustrates device reproducibility. Here the mobile device30may document the learning model20using the blockchain70. That is, the mobile device30(again illustrated as the smartphone32) may integrate the raw electronic data22and/or the result80(such as the suggestion24, the prediction26, and/or the local update50illustrated inFIG.1)) as electronic data records in the blockchain70. The mobile device30may also hash the raw electronic data22and/or the result80(using the hashing algorithm76) and distribute the cryptographic hash value(s)78via the blockchain70. The mobile device30may then send the blockchain70to any recipient, such as the destination device82. The blockchain70may thus be individualized or dedicated to documenting the learning model20locally executed by the mobile device30. The blockchain70may thus contain or specify the device identifier58that uniquely identifies the mobile device30. The device identifier58(such as any unique alphanumeric combination) may uniquely identify or associate the blockchain70with the mobile device30. The blockchain70may thus historically record the learning model20, perhaps according to date, time, geographic location (perhaps using global positioning system information), and the device identifier58.

FIG.7illustrates noun chaining. Here exemplary embodiments may generate data records for many different learning models20. Again, as this disclosure above explained, the mobile device30may store and execute many different predictive software applications (such as the aforementioned “apps” for mapping services, dating services, and home automation). Each different learning model20may thus gather different electronic data22to generate different results80. Exemplary embodiments may thus organize or specify data records according to a noun identifier90. The noun identifier90uniquely identifies a source that generates or uses the electronic data22to generate the result80. The noun identifier90may thus be an alphanumeric hardware, software, and/or user descriptor. For example, if the electronic data22is sourced from, or used by, an internal hardware component, the device identifier58may uniquely identify the internal hardware component (such as the smartphone32, a processor92, a memory device94, and/or network interface96). If the electronic data22is sourced from, or used by, a software application, an alphanumeric model identifier98may uniquely identify the learning model20. The noun identifier90may also include an alphanumeric user identifier100that uniquely identifies a current user of the smartphone32. When any data or information is integrated into the blockchain70(illustrated inFIGS.3-6), exemplary embodiments may also add, append, incorporate the corresponding noun identifier90, device identifier58, model identifier98, and/or user identifier100to distinguish between data records from different sources. Exemplary embodiments may also hash the noun identifier90, device identifier58, model identifier98, and/or user identifier100as further cryptographic differentiation.

Noun chaining may thus be useful for the Internet of Things. As the reader may be aware, more and more devices are equipped with network access. Smartphones, tablet computers, laptop computers, and other processor-controlled devices commonly have Internet access. Moreover, refrigerators and other appliances are also offered with Internet access. Indeed, in the coming years, millions of devices per square mile are predicted to have network access. Exemplary embodiments may thus generate an individual blockchain70per device, per software application (per learning model20), and/or per user. Different blockchains70, in other words, may be dedicated to data records associated with each noun identifier90, each device identifier58, each model identifier98, and/or each user identifier100.

FIG.8illustrates combinational noun chaining. Here different blockchains70may be dedicated to data records associated with intersecting or combinational noun identifiers90. Again, as this disclosure above explained, the mobile device30may store and execute many different learning models (simply illustrated as reference numeral20a-c) (such as the aforementioned “apps” for mapping services, dating services, and home automation). Exemplary embodiments may thus generate corresponding, multiple blockchains70a-c, which each different blockchain70a-cdedicated to a different one of the learning models20a-c.FIG.8, for example, illustrates a first blockchain70aintegrating the local update50agenerated by the smartphone32executing a first learning model20a. The first blockchain70a, in other words, may integrate data records associated with the noun identifier90a. A second blockchain70bmay integrate data records associated with the noun identifier90b. The second blockchain70b, in other words, is dedicated to documenting any usage, activity, or data associated with the smartphone32executing a second learning model20b. Still a third blockchain70cmay be dedicated to documenting the usage, activity, or data22associated with a third learning model20c. Exemplary embodiments may thus generate the multiple blockchains70a-c, which each different blockchain70dedicated to a different one of the learning models20a-c.

FIG.9illustrates master chaining. Because exemplary embodiments may generate multiple different blockchains70a-c(perhaps according to each noun identifier90a-c),FIG.9illustrates a master blockchain110. The master blockchain110may incorporate one or more of the individual blockchains70a-c. The master blockchain110may thus be associated with, or integrate, one or more sub-blockchains112. As a simple example, suppose that the master blockchain110is dedicated to the mobile device30(again illustrated as the smartphone32). A first sub-blockchain112amay be dedicated to the first learning model20astored and executed by the smartphone32. The first sub-blockchain112amay integrate data records describing the raw electronic data22aused by, and/or the local change50agenerated by, the first learning model20a. Another, second sub-blockchain112bmay be dedicated to the second learning model20bstored and executed by the smartphone32. Still a third sub-blockchain112cmay be dedicated to the third learning model20cstored and executed by the smartphone32. Similarly, the second and the third sub-blockchains112band102cintegrate data records describing the raw electronic data22band22cused by, and/or the local change50band50cgenerated by, the second and third learning models20band20c. The master blockchain110may thus document application-specific information according to the noun identifier90a-c.

Blockchain dedication, in general, may be based on the noun identifier90. The noun identifier90may represent one or more of the device identifier58, the model identifier98, and/or the user identifier100. The noun identifier90may thus be any alphanumeric combination that uniquely identifies the source that generates or uses the electronic data22to generate the local update50. The noun identifier90may thus pinpoint the mobile device30, the learning model20, and even the current user generating training data. Indeed, as the reader understands, people often share computers, tablets, smartphones, and other devices. As the mobile device30(again illustrated as the smartphone32) executes the different learning models20a-c, exemplary embodiments may track the sub-blockchains112a-caccording to the corresponding noun identifier90(the device identifier58, the model identifier98, and/or the user identifier100). Suppose, for example, a first user (e.g., user identifier100a) selects a dating application (learning model20ahaving model identifier98a), resulting in the first sub-blockchain112a. A second user (e.g., user identifier100b) then picks up the smartphone32(the device identifier58) to use a mapping application (learning model20bhaving model identifier98b), resulting in the second sub-blockchain112b. A third user (e.g., user identifier100c) then picks up the smartphone32to suggest a jogging route (learning model20chaving model identifier98c), resulting in the third sub-blockchain112c. Exemplary embodiments may thus integrate data records that individually specify the source “noun” (e.g., the device, the learning model20, and/or the user). The master blockchain110may thus document device-specific, user-specific, and application-specific information.

The master blockchain110and the sub-blockchains112may have any structure.FIG.9, for simplicity, illustrates the sub-blockchains112within, or internal to, the master blockchain110. However, exemplary embodiments need not have a physical, internal/external arrangement. That is, the master blockchain110need not physically contain the one or more sub-blockchains112. In actual practice the master blockchain110may have blocks or regions of data, with each block or region specifying at least a portion of the sub-blockchains112a. Each different block, in other words, may specify, group, or arrange data records having the same or similar noun identifier90, device identifier58, model identifier98, and/or user identifier100. Indeed, certain blocks of data or other portions may be reserved for a corresponding one of the sub-blockchains112. Data records referenced by the master blockchain110and/or the sub-blockchains112may thus be containers or ranges dedicated to a particular device, learning model20, and/or user. The master blockchain110and/or the sub-blockchains112may additionally or alternatively group or arrange packets of data according to the noun identifier90, device identifier58, model identifier98, and/or user identifier100. A packetizing protocol (such as the well-known Internet protocol) may be used to arrange commonly-associated packets of data.

Exemplary embodiments are thus helpful in federated learning. Federated learning aggregates individualized usage of a population of devices to generate an improvement to the learning model20. Federated learning allows the population of devices to collaboratively learn and to improve the predictive learning model20, based on their individual local updates50. The blockchain70may thus store original versions of any data described by the local update50and/or used to train or improve the learning model20. The original versions of the data may be raw and unencrypted, encrypted, and/or hashed (using the hashing algorithm76above discussed). Indeed, the cryptographic hash values78may be used to validate the original versions of the data. The mobile device30may even store and execute trusted platform modules to sign the electronic data22, thus proving that the mobile device30, and only the mobile device30, generated the electronic data22. As each piece of data—or its hash thereof—may be stored in the blockchain70, any missing data is immediately obvious (that is, if the hash value78is documented in the blockchain70, then its corresponding unhashed data may or should also be documented in the blockchain70). Exemplary embodiments thus allow reproducibility of data in federated learning using the blockchain70.

FIGS.10-12are more detailed illustrations of an operating environment, according to exemplary embodiments.FIG.10illustrates the mobile device30communicating with the server54via the communications network52. Again, most readers are thought familiar with the smartphone32, but the mobile device30may be any mobile or stationary processor-controlled device. The smartphone32has the processor92(e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes the learning model20stored in the local memory device94. The smartphone32also has the network interface96to the communications network52, thus allowing two-way, bidirectional communication with the server54. The learning model20includes instructions, code, and/or programs that cause the smartphone32to perform operations, such as generating the local update50to the learning model20based on the electronic data22. The local update50may additionally include or specify the noun identifier90(e.g., the device identifier58, the model identifier98, and/or user identifier100) generating or sourcing the local update50. The smartphone32may send the local update50via the communications network52to the server54for analysis. The smartphone32, however, may additionally or alternatively integrate the electronic data22and/or the local update50into the blockchain70for distribution/publication to any destination (again, perhaps the server54). Moreover, exemplary embodiments may call or invoke the hashing algorithm76to act on the electronic data22and/or the local update50to generate the cryptographic hash value(s)78.

FIG.11further illustrates the server54. The server54may have a processor120(e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes a server-side algorithm122stored in a local memory device124. The server-side algorithm122may include software code or instructions that apply the artificial intelligence40to the electronic data22, and/or the local update50, reported by the mobile device30. The server54thus generates the learning modification60to the learning model20, based on the usage or activity reported by the mobile device30. The server-side algorithm122thus includes instructions, code, and/or programs that cause the server54to perform operations, such as improving or refining the learning model20based on information sent from the mobile device30. Indeed, in a federated, collaborative learning environment, the server54may aggregate many local updates50from many client devices to determine the learning modification60to the learning model20(as explained with reference toFIG.2). The field population of devices executing the learning model20, in other words, may collaboratively train the learning model20, based on the local update(s)50. The server54may thus generate the modified learning model62to implement a performance enhancement, perhaps based on an average or other statistical analysis of the local update50.

FIG.12further illustrates the documentary evidence72. Here the server54may historically record and track any changes to the learning model20. That is, exemplary embodiments may use the blockchain70to prove custody of any data used by, and/or changes made to, the learning model20. For example, the server54may integrate the electronic data22, the local update50, and/or the learning modification60into the blockchain70for distribution or publication. The blockchain70may further integrate or associate the corresponding noun identifier90to uniquely identify the source(s) responsible for the changes to the learning model20. Moreover, exemplary embodiments may apply the hashing algorithm76to generate the one or more cryptographic hash values78and to integrate the hash values78into the blockchain70.

Exemplary embodiments may use any hashing function. Many readers may be familiar with the SHA-256 hashing algorithm. The SHA-256 hashing algorithm acts on any electronic data or information to generate a 256-bit hash value78as a cryptographic key. The key is thus a unique digital signature. There are many hashing algorithms, though, and exemplary embodiments may be adapted to any hashing algorithm.

Exemplary embodiments may be applied regardless of networking environment. Exemplary embodiments may be easily adapted to stationary or mobile devices having cellular, wireless fidelity (WI-FI®), near field, and/or BLUETOOTH® capability. Exemplary embodiments may be applied to mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the IEEE 802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). Exemplary embodiments, however, may be applied to any processor-controlled device operating in the radio-frequency domain and/or the Internet Protocol (IP) domain. Exemplary embodiments may be applied to any processor-controlled device utilizing a distributed computing network, such as the Internet (sometimes alternatively known as the “World Wide Web”), an intranet, a local-area network (LAN), and/or a wide-area network (WAN). Exemplary embodiments may be applied to any processor-controlled device utilizing power line technologies, in which signals are communicated via electrical wiring. Indeed, exemplary embodiments may be applied regardless of physical componentry, physical configuration, or communications standard(s).

Exemplary embodiments may utilize any processing component, configuration, or system. Any processor could be multiple processors, which could include distributed processors or parallel processors in a single machine or multiple machines. The processor can be used in supporting a virtual processing environment. The processor could include a state machine, application specific integrated circuit (ASIC), programmable gate array (PGA) including a Field PGA, or state machine. When any of the processors execute instructions to perform “operations,” this could include the processor performing the operations directly and/or facilitating, directing, or cooperating with another device or component to perform the operations.

Exemplary embodiments may packetize. The mobile device30and the server54may have network interfaces to the communications network52, thus allowing collection and retrieval of information. The information may be received as packets of data according to a packet protocol (such as the Internet Protocol). The packets of data contain bits or bytes of data describing the contents, or payload, of a message. A header of each packet of data may contain routing information identifying an origination address and/or a destination address.

FIGS.13-14illustrate data verification, according to exemplary embodiments. Here exemplary embodiments may discern or differentiate an original version130from a later or current version132. While data verification may be performed by any device, for simplicityFIG.13illustrates the server54. For example, when the smartphone32reports the local update50, the local update50has the original version130generated or saved at approximately a date and time of a creation134. The server-side algorithm122may thus cause the server54to obtain or retrieve the current version132of the local update50. As the reader may understand, the current version132(perhaps as of a current date and time) may be different, perhaps only slightly, from the original version130generated or saved approximately at the creation134. Any difference between the original version130and the current version132may indicate an unintentional, or intentional, change to the local update50.

Exemplary embodiments may verify, or deny, originality. Exemplary embodiments may perform cryptographic comparisons to discern data differences. That is, the server54may retrieve the cryptographic hash value(s)78generated from hashing the original version130of the local update50. The server54may also retrieve and hash the current version132of the local update50(using the same cryptographic hashing algorithm76) to generate one or more verification hash values136. If the verification hash values136match the cryptographic hash values78generated from the original version130of the local update50, then the local update50has not changed since the date and time of creation134. That is, the current version132of the local update50is the same as the original version130, unaltered, and thus authentic138. However, if the verification hash values136(generated from hashing the current version132of the local update50) fail to match the cryptographic hash values78generated from the original version130of the local update50, then the current version132has changed since the date and time of creation134. Exemplary embodiments, in other words, reveal an alteration that may indicate the current version132is inauthentic140. Exemplary embodiments may thus generate a flag or other alert142to initiate further investigation.

The blockchain70may thus provide the documentary evidence72. If the blockchain70integrates data or information representing the original version130, then the blockchain70provides historical records for future verification. Any recipient of the blockchain70may inspect its data records and obtain or retrieve the data representing the original version130and/or its corresponding cryptographic hash value(s)78. If the current version132(and/or its corresponding verification hash value136fails to substantially or exactly match, then a difference has been detected and the current version132is inauthentic140.

FIG.14expands originality. Here the blockchain70may historically record the original version130of any data (such as the suggestion24, prediction26, historical data34, habitual activity36, predicted future activity38, local change56, and/or learning modification60explained herein). The blockchain70may also historically record the original version130of the noun identifier90(e.g., the device identifier58, the model identifier98, and/or user identifier100, as also explained herein). The blockchain70may also historically record the hash values78representing any of these original versions130. Any recipient of the blockchain70(such as the destination device82) may thus inspect the data records incorporated into the blockchain70and obtain or retrieve the data representing the original versions130and/or their corresponding cryptographic hash values78. If any current version132(and/or its corresponding verification hash values136) fails to substantially or exactly match, then verification may fail.

Exemplary embodiments thus present a simple and effective verification mechanism. Cryptographic hashing may be used to make quick verification decisions. If any entity matches cryptographic digital signatures representing different versions, then perhaps verification is complete and no further investigation is required. But if the current version132has changed, the digital signatures will differ, perhaps even substantially. Indeed, even a change to a single bit or character can produce a noticeable difference in hash values. So, if the digital signatures are different, the current version132may fail an authentication (e.g., the authentic138or inauthentic140determination). An auditor or software developer, in other words, may thus simply and quickly discern whether additional investigative scrutiny is needed. The software developer may thus use the blockchain70to archive development efforts for historical use and analysis.

FIG.15illustrates trusted platforming, according to exemplary embodiments. Here exemplary embodiments may cryptographically hash the noun identifier90as verification of originality. The noun identifier90, as previously explained, uniquely sources the mobile device30(e.g., the device identifier58), the learning model (e.g., the model identifier98), and/or the current user (e.g., the user identifier100) (as explained with reference toFIG.7). Exemplary embodiments may thus cryptographically hash the noun identifier90(using the hashing algorithm76) to cryptographically bind any change to the learning model20. For example, exemplary embodiments may use a trusted platform module150to securely generate the hash values78and to limit or specify permitted usage. The local update50, for example, may thus be digitally and cryptographically signed and added to the blockchain70, thus later proving that the mobile device30, and only the mobile device30, generated the local update50. Trusted platforming is generally known, so a detailed explanation is not necessary.

FIG.16further illustrates data verification, according to exemplary embodiments. Here the blockchain70may be used to identify missing data records. Suppose the blockchain70initially integrates the electronic data22and its corresponding hash value78. Months or even years later, the blockchain70may be inspected for the same data records. That is, at any later time after the creation134, the blockchain70may be historically inspected for the electronic data22and its corresponding hash value78. If only the hash value78is present at the later time, then exemplary embodiments may infer that the blockchain70has been modified or altered. That is, if the data records representing the electronic data22are missing, then perhaps the data records have been intentionally tampered with and altered. Similarly, if only the electronic data22is present and its corresponding hash value78is missing, fraud may be present.

FIG.17illustrates metadata160, according to exemplary embodiments. Here exemplary embodiments may augment the local update50with the metadata160. The metadata160may be any information that aids in documenting the local update50, the learning model20, the original version130, and/or even the noun identifier90(e.g., the device identifier58, the model identifier98, and/or user identifier100, as above explained). The metadata160may also describe any corresponding cryptographic hash value(s)78. The metadata160may even describe software programming changes to the learning model20, perhaps using keywords. The metadata160may describe the date and time of the creation134and/or an informational summary. The metadata160may also describe a location (such as GPS information at the creation134, as determined by a GPS system). The metadata160may describe a formatting of the local update50, structured data used or present within the local update50, and even programming instructions. Exemplary embodiments may thus integrate the metadata160, and/or its corresponding cryptographic hash values78, into the blockchain70.

FIGS.18-19illustrate a noun key170, according to exemplary embodiments. Once the noun identifier90(e.g., the device identifier58, the model identifier98, and/or the user identifier100, as above explained) is determined and/or retrieved, the noun identifier90may be hashed using the cryptographic hashing algorithm76(as above explained) to generate one or more cryptographic noun keys170. The cryptographic noun key170may then incorporated into and/or distributed via the blockchain70. Once any recipient receives the blockchain70, the recipient may reverse lookup the noun key170to retrieve the corresponding noun identifier90. For example, the recipient device82may send a key query to a database172of keys.FIG.18illustrates a key server174locally storing the database172of keys in local memory. The database172of keys converts or translates the noun key170back into its corresponding noun identifier90.FIG.19illustrates the database172of keys is illustrated as a table that electronically maps, relates, or associates different cryptographic noun keys170to different noun identifiers90. The key server174identifies the corresponding noun identifier90and sends a key response. The key response, for example, identifies the device identifier58, the model identifier98, and/or the user identifier100as a source of the local update50. Exemplary embodiments may thus identify the mobile device30, the learning model20, and the user associated with the local update50.

FIGS.20-23illustrate secret sharing, according to exemplary embodiments. By now the reader understands that the electronic data22and/or the local update50may contain sensitive information (such as the user's personal and device information). The electronic data22and/or the local update50, in plain words, may contain secret data180. If the secret data180was to fall into the wrong hands, the secret data180may be nefariously used by a rogue entity.

Exemplary embodiments may thus protect the secret data180. When the mobile device30generates the local update50, exemplary embodiments may split the local update50into multiple pieces termed shares182. The server54, for example, may call or invoke a secret sharing algorithm184to generate the shares182. The server54may then distribute one or more of the shares182via the blockchain70.

FIG.21further illustrates secret sharing. Here, though, the server54may integrate any one or more of the shares182into the multiple blockchains70. While exemplary embodiments may utilize any number of different blockchains70,FIG.21again illustrates the simple example of the three (3) blockchains70a-c. The blockchains70a-cmay then be distributed to the same destination or to different destinations. That is, some of the shares182(such as a first subset186) may be integrated into the first blockchain70aand distributed (via the communications network52illustrated inFIGS.2-4and10) to a first group74aof peer devices. A second subset188of the shares182may be integrated into the second blockchain70band distributed to a second group74bof peer devices. Still more shares182(such as the remaining portion or pieces in a third subset190) may be integrated into the third blockchain70cand distributed to a third group74cof peer devices (such as any destination device82). Different collections of the shares182, in other words, may be distributed via different blockchains70a-cto different destinations/devices.

Exemplary embodiments may thus stash the shares182ain the multiple blockchains70a-c. Because the local update50may be split into the multiple shares182, any one or more recipient devices must possess a sufficient minimum number MMin(illustrated as reference numeral192) of the shares182before the local update50may be recovered. That is, possession of an insufficient number of the shares182guarantees that the local update50remains unknown and confidential. In other words, no single one of the multiple blockchains70a-cmay store the requisite minimum number MMin192of the shares182to launch a brute-force attack on the local update50. Even multiple ones of the blockchains70a-cmay be purposefully designed to never exceed the requisite minimum number MMin192of the shares182, perhaps thus forcing a hacker to compromise several or all of the blockchains70a-c. A rogue attack, in simple words, would have to access and compromise multiple blockchains70before jeopardizing the local update50.

Exemplary embodiments thus present another elegant solution. The sensitive, secret local update50may be secretly shared via the one or more blockchains70a-c. Even if the blockchains70a-care dispersed to trusted peer devices, the peer devices still cannot discern the local update50until the threshold minimum number MMin192of the shares182is obtained. Exemplary embodiments thus purposefully add a second-layer of protection, beyond merely trusted receipt of the blockchain70. The trusted peers simply do not have access to the local update50until the minimum number MMin192of the shares182is obtained.

Any secret sharing scheme may be utilized. The reader is perhaps familiar with Shamir's Secret Sharing Algorithm, which is a well-known cryptographic algorithm. Exemplary embodiments may thus divide the local update50into unique parts (e.g., the shares182), with each individual share182being different from other shares182. However, there are many secret sharing or splitting schemes and algorithms for distributing a secret, and exemplary embodiments may be applied regardless of any particular scheme or algorithm.

FIG.22illustrates a sharing strategy200. Here exemplary embodiments may call the sharing algorithm184to retrieve and/or to implement the sharing strategy200that defines distribution via the multiple blockchains70to protect the local update50. Suppose, for example, that the total number NS(illustrated as reference numeral202) of the shares182defines a number NB(illustrated as reference numeral204) of the different blockchains70. The total number NS202of the shares182, in other words, may relate by a ratio to the number NB204of blockchains70that must be used. As a simple example, the ratio may be

NSNB=10,000,
where the total number NS202of the shares182is ten thousand (10,000) times the number NB204of blockchains70that must be used. Again, as a simple example, if the local update50is associated with one million (1,000,000) shares182, then one hundred (100) different blockchains70must be generated and distributed. The sharing strategy200, in other words, may set a maximum number NSmax(illustrated as reference numeral206) of shares182integrated into any single blockchain70. The sharing strategy200, in other words, may thus limit the number of the shares182exposed by any individual blockchain70.

FIG.23further illustrates the sharing strategy200. Here, though, the number NB204of blockchains may be based on the number of recipients. That is, the total number NR(illustrated as reference numeral208) of the recipients may define the number NB204of the different blockchains70. The greater the recipients, in other words, then the greater the NB204of blockchains70that must be used. Again, suppose that the sharing strategy200may again be defined as the ratio

NRNB=100,
where the total number NR208of the recipients is one hundred (100) times the number NB204of blockchains70that must be used. Again, as a simple example, if there are ten thousand recipients, then one hundred (100) different blockchains70must be generated and distributed. The sharing strategy200, in other words, may set a maximum number NRmax(illustrated as reference numeral210) of recipients per blockchain70. The sharing strategy200, in other words, may thus limit the number of the shares182exposed by any individual blockchain70.

The sharing strategy200may be implemented as logical rules. If the sharing strategy200is mathematically defined (such as the ratio above discussed), the sharing strategy200may be expressed as logical statements involving mathematical expressions. Exemplary embodiments may code or program the sharing strategy200to achieve policy goals and/or security objectives.

FIG.24illustrates fingerprinting, according to exemplary embodiments. Some users of the learning model20may be concerned about exposing their personal usage. That is, some users may not want the local update50to reveal some, any, or all of the raw electronic data22gathered by, or processed by, the learning model20. Indeed, some federated learning models alieve privacy concerns by locally storing the raw electronic data22without exposure to the cloud/Internet. Exemplary embodiments may thus generate a data fingerprint220based on the raw electronic data22gathered by, or processed by, the learning model20. The data fingerprint220may be incorporated into the local update50, but the data fingerprint220may only reveal a subset of the electronic data22used by the learning model20. For example, the learning model20may call and/or execute a fingerprinting module that generates the data fingerprint220. The fingerprinting module may be a subroutine that applies a fingerprinting algorithm to the electronic data22used by the learning model20. The fingerprinting module, additionally or alternatively, apply the fingerprinting algorithm to the local update50. Regardless, the fingerprinting module generates and stores the data fingerprint220as a smaller, less bulky data file and/or a shorter bit string. The fingerprinting algorithm may also use data hashing (such as the hashing algorithm76) to generate the data fingerprint220. Regardless, the local update50may contain, or be representative of, the data fingerprint220based on the electronic data22used by the learning model20. When the server54receives the data fingerprint220, the server54may update the learning model20while alleviating privacy concerns.

The data fingerprint220also allows data reproducibility. Even though the data fingerprint220may be a much smaller file or shorter bit string (e.g., cryptographic key), the data fingerprint220is different from, and not the same, as the electronic data22used by the learning model20. The data fingerprint220may thus guarantee, at the very least, that some of the electronic data22is reported to the server54for training the federated learning model20. The data fingerprint220may also guarantee that none of the electronic data22is omitted from analysis. Exemplary embodiments may thus integrate the raw electronic data22and/or the data fingerprint220in the blockchain70. Integrating both the electronic data22and the data fingerprint220allows a recipient of the blockchain70to both verify and reproduce the electronic data22, based on the data fingerprint220. A single API call, for example, may be used to retrieve the data fingerprint220, perhaps with an additional payload as the electronic data22.

FIG.25further illustrates master chaining, according to exemplary embodiments. Here the master blockchain110may be dedicated to a single device, a single user, and/or the single learning model20.FIG.25, for example, illustrates the master blockchain110dedicated to the mobile device30(again illustrated as the smartphone32). That is, the master blockchain110may be associated with the device identifier58that uniquely identifies the smartphone32. Because the smartphone32may store and execute the many different learning models20a-c, the sub-blockchain112amay be dedicated to the first learning model20a. The sub-blockchain112bmay be dedicated to the second learning model20b(such as a dating application). The sub-blockchain112cmay be dedicated to the third learning model20c(such as a walking application). The sub-blockchains112a-cmay integrate their respective raw electronic data22a-c, their respective local updates50a-c, their respective data fingerprints220a-c, and/or their respective cryptographic hash values78a-c. The sub-blockchains112a-cmay also integrate their respective noun identifiers90a-c. Because the master blockchain110is dedicated to the smartphone32, the sub-blockchains112a-cmay have the common device identifier58. If the learning models20a-chave a common user, then the sub-blockchains112a-cmay have the common user identifier100. For simplicity,FIG.25illustrates the smartphone32distributing or publishing the master blockchain110to the destination device82. However, the master blockchain110may be sent or routed to any destination or recipient.

Exemplary embodiments may also include a central repository. Even though the master blockchain110may be used a publication and/or archival system, the server54may also act as a clearinghouse or central repository for all the activities conducted by the smartphone32. That is, because there may be multiple blockchains70(as this disclosure explains), the server54may store any blockchain70in an electronic database. The electronic database may have entries that electronically map, relate, or associate the blockchain70to the corresponding noun identifier90(e.g., the device identifier58, the model identifier98, and/or user identifier100). The electronic database may thus organize and/or group the data records contained within, or referenced by, the master blockchain110and/or the multiple sub-blockchains112a-caccording to the mobile device30, the learning model20, and/or the current user. The server54may thus receive queries from client devices specifying the noun identifier90and identify the corresponding data records distributed via the master blockchain110and/or the multiple sub-blockchains112a-c. The server54may even send query responses to the client devices, and the query responses may specify or even include the corresponding data records. The server54may thus act as a historical repository for the activities conducted by the smartphone32, the learning model20, and/or the current user. The server may historically log the local update50(such as the data fingerprint220) in the electronic database in electronic association with the noun identifier90. Again, then, the server54may act as a historical repository for the activities conducted by the smartphone32, the learning model20, and/or the current user.

FIG.26is a flowchart illustrating a method or algorithm for reproductive federated learning, according to exemplary embodiments. The electronic data22and/or the local update50is reported to the server54(Block250). If secret sharing is desired (Block252), then the electronic data22and/or the local update50is split into the shares182(Block254). If cryptography is desired (Block256), then the electronic data22, the local update50, and/or the shares182are hashed using the cryptographic hashing algorithm36(Block258). The blockchain(s)70,110, and/or112are published (Block260). When a recipient receives the blockchain(s)70,110, and/or112(Block262), the recipient may verify the original version130to the current version132(Block264).

FIG.27is a schematic illustrating still more exemplary embodiments.FIG.27is a more detailed diagram illustrating a processor-controlled device350. As earlier paragraphs explained, the learning model20and/or the server-side algorithm122may partially or entirely operate in any mobile or stationary processor-controlled device.FIG.27, then, illustrates the learning model20and/or the server-side algorithm122stored in a memory subsystem of the processor-controlled device350. One or more processors communicate with the memory subsystem and execute either, some, or all applications. Because the processor-controlled device350is well known to those of ordinary skill in the art, no further explanation is needed.

FIG.28depicts other possible operating environments for additional aspects of the exemplary embodiments.FIG.28illustrates the learning model20and/or the server-side algorithm122operating within various other processor-controlled devices350.FIG.28, for example, illustrates that the learning model20and/or the server-side algorithm122may entirely or partially operate within a set-top box (“STB”) (352), a personal/digital video recorder (PVR/DVR)354, a Global Positioning System (GPS) device356, an interactive television358, a tablet computer360, or any computer system, communications device, or processor-controlled device utilizing any of the processors above described and/or a digital signal processor (DP/DSP)362. Moreover, the processor-controlled device350may also include wearable devices (such as watches), radios, vehicle electronics, clocks, printers, gateways, mobile/implantable medical devices, and other apparatuses and systems. Because the architecture and operating principles of the various devices350are well known, the hardware and software componentry of the various devices350are not further shown and described.

Exemplary embodiments may be applied to any signaling standard. Most readers are thought familiar with the Global System for Mobile (GSM) communications signaling standard. Those of ordinary skill in the art, however, also recognize that exemplary embodiments are equally applicable to any communications device utilizing the Time Division Multiple Access signaling standard, the Code Division Multiple Access signaling standard, the “dual-mode” GSM-ANSI Interoperability Team (GAIT) signaling standard, or any variant of the GSM/CDMA/TDMA signaling standard. Exemplary embodiments may also be applied to other standards, such as the I.E.E.E. 802 family of standards, the Industrial, Scientific, and Medical band of the electromagnetic spectrum, BLUETOOTH®, and any other.

Exemplary embodiments may be physically embodied on or in a computer-readable storage medium. This computer-readable medium, for example, may include CD-ROM, DVD, tape, cassette, floppy disk, optical disk, memory card, memory drive, and large-capacity disks. This computer-readable medium, or media, could be distributed to end-subscribers, licensees, and assignees. A computer program product comprises processor-executable instructions for reproducing and/or verifying data in learning models, as the above paragraphs explained.

While the exemplary embodiments have been described with respect to various features, aspects, and embodiments, those skilled and unskilled in the art will recognize the exemplary embodiments are not so limited. Other variations, modifications, and alternative embodiments may be made without departing from the spirit and scope of the exemplary embodiments.