Singing Machine

Abstract

A thing machine is provided having a processor, non-transitory memory, a non-transitory computer-readable medium, and executable machine code P(TM). [Solution] P(TM) is composed of a first set of executable machine code operations having one or more executable machine code P(TM(i)) operations, each executable machine code P(TM(i)) operation being configured as an implementation of an algorithmic procedure of the model, the first P(TM(i)) providing operations that self-configure a first vocabulary of things in the non-transitory memory of the thing machine, the things representing things that the processor can execute as operations and a set of things that can execute operations, and at least one P(TM(i)) machine code operation is executed to configure a second thing vocabulary in the non-transitory memory of the thing machine representing a core vocabulary that can provide an application.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 396,332, entitled "THING MACHINE," filed Sep. 19, 2016, which is incorporated herein by reference in its entirety. This application also incorporates by reference in its entirety U.S. Provisional Patent Application No. 62 / 288,545, entitled Optical Identity System and Methods, filed Jan. 29, 2016.

[0002] FIELD OF THEINVENTION The present invention relates to computer architecture and design, and more particularly to a Thing Machine that represents the operations that a Thing Machine can perform and the Things on which the operations are performed as instances of Things supervised in non-transient memory using a multi-dimensional graph model. [Background technology]

[0003] 2. Background of the Invention For a quarter century, web browsers have been used to view web pages. Browsers have evolved significantly over the last 25 years, but ultimately still use a client-server model to render web pages. In modern browsers, cookie information can now be synchronized in the cloud, so that state information is shared between different devices used.

[0004] For 25 years, the primary access to the web has been through the use of desktop and laptop computers. Mobile devices offering web browsers began to appear around 1996. Nine years later, Google announced that over half of Google searches came from mobile devices (at least in the US).

[0005] It is important to note that a significant number of over 5 billion web pages are not mobile friendly. For example, in 2016, it was estimated that 54% of small businesses have a website, and of those websites, only 64% are mobile friendly. Thus, only 37% of small businesses have a mobile-friendly website. It is interesting to note that small businesses account for over half of sales in the United States each year.

[0006] Many users, frustrated by the lack of mobile-friendly web pages, have downloaded retailers' mobile apps to make their experience more productive. Each app is dedicated to a specific business, and app icons consume real estate on the screen display, eventually becoming cluttered as more and more apps are downloaded. As an end user, you have to spend time organizing the apps on your phone so that you can productively navigate the plethora of icons to find the exact app you're looking for. Constant updates to the application programming interfaces (APIs) of the phone's operating system require dedicated development teams to ensure that the apps on your phone are up to date. This adds an expense that many small businesses simply cannot afford to pay.

[0007] The emergence of web-enabled voice-activated devices is becoming more commonplace. A generation of kids is growing up knowing they can ask their phone for directions to a friend's house. Smartphones, alarm clocks, smart watches, smart TVs, Amazon Echo, home automation systems, and motorcycle helmets are just a few examples of voice-activated devices.

[0008] Network-enabled devices include thermostats, locks, cameras, generators, coffee machines, washers and dryers, light switches, security systems, toys, irrigation systems, and many other devices and sensors. This interconnected world is sometimes referred to as the Internet of Things.

[0009] If you could stand in the center of the Internet and look at the edge, you would see all the things connected to the Internet. In this document, we call this the Internet of Things that are Devices and Sensors. If you go to the edge of the Internet, pick up a device, and look back to the center, you would see the services that are offered and known as the Internet of Services.

[0010] The world became complicated when one realized that services were the things being offered, and suddenly there was a grey area between the Internet of Things as devices and sensors, and the Internet of Things as services. Physical things and virtual things added a level of ambiguity to the meaning of the Internet of Things, and this created confusion in the marketplace.

[0011] To further complicate things, many physical devices can often communicate using multiple protocols, including GSM, CDMA, LTE, SS7, Zigbee, Z-Wave, WeMo, Near Field Communication (NFC), Bluetooth, Thread, BLE, etc. You can use your cell phone to pay a bill, for example, by simply holding the phone up to a cash register, using NFC. Similarly, you can pair and connect your cell phone to a car audio system, using Bluetooth. In either case, the device does not use Internet protocols, but we still consider the cell phone to be a thing in the Internet of Things.

[0012] Since 2005, over 35 million interoperable Z-Wave devices have been sold (Z-Wave Alliance). A Z-Wave network controller is used to manage a Z-Wave network of devices. Technically, an Internet-enabled Z-Wave network controller is used to communicate over the Internet, but the controller still uses Z-Wave to communicate with the Z-Wave devices. This adds another layer of confusion to the definition of the Internet of Things, because a Z-Wave device is a thing, but communicates with a controller that may or may not be an Internet of Things thing.

[0013] In all of this confusion over the definition of the Internet of Things, it is not surprising that the International Telecommunication Union does not even use the keyword Internet in its description of the Internet of Things. Instead, the International Telecommunication Union states: The global infrastructure of the information society that enables advanced services by interconnecting things (physical and virtual) based on existing and evolving interoperable information and communication technologies (ITU-T) The one thing we can all agree on is that there are things.

[0014] We classify things to describe and categorize them. Some things are concepts like monetary value, legal tender, documents like birth certificates, copyrights, titles, bills of sale, or assets. Things can represent events, alerts, units of measurement, geolocation, or time. Other things are devices and sensors, objects like cell phones, iPads, or web pages. Even actions are things, as in: Don't just stand there, do something.

[0015] FIG. 1 is a schematic diagram showing a primitive flow chart of how a person may respond to an imperative command. First, one or more of the person's senses are enabled with a verb action, such as hearing a trainer telling them what to do next. You use the listening vocabulary of a particular language to parse the spoken words and generate thoughts that represent the imperative command. Then you evaluate the command and decide what to do next. Did I understand correctly? Can I do it? Do I want to do it? Perhaps I'm tired and need to rest instead.

[0016] The response may be an acknowledgement that the user understands what is being asked of them, or it may be the performance of the action itself. An OK may be conveyed by making a thumbs up gesture, a facial expression of agreement or disapproval, or using the speech vocabulary of the given language. Alternatively, in response to a command to jog in place, the user may simply start jogging in place.

[0017] The word "verb" itself is a noun meaning a word that is usually one of the main parts of a statement and expresses an action, occurrence, or state of being (see Merriman Webster Dictionary). An action is the doing of something or the process of doing something.

[0018] Some things express actions, and other things can be said to be things on which actions can act. This leads to the singularity of things: All things are Things. Summary of the Invention [Problem to be solved by the invention]

[0019] At the current state of the art, the phrase "Internet of Things" has numerous definitions that focus primarily on Internet-connected devices and sensors instead of things, which are services provided to subscribers identified by a subscriber identifier and password, each of which is a thing. This places limitations on how implementations of algorithmic procedures to be implemented as machine code can be modeled, thus adding inefficiencies and costs. [Means for solving the problem]

[0020] Summary of the Invention An embodiment of the present invention provides a thing machine that represents the operations it can perform, and the things on which operations are performed, as instances of things that are managed in non-transient memory using a multi-dimensional graph model.

[0021] The thing machine includes a processor, a non-transitory memory, a non-transitory computer readable medium, and executable machine code P(TM), P(TM) being comprised of a first set of executable machine code operations having one or more executable machine code P(TM(i)) operations, each executable machine code P(TM(i)) operation being configured as an implementation of an algorithmic procedure of a model, a first P(TM(i)) providing operations that self-configure a first vocabulary of things in said non-transitory memory of the thing machine, said things representing things that said processor can execute as operations and a set of things on which operations can be executed, and at least one P(TM(i)) machine code operation is executed to configure a second thing vocabulary in the non-transitory memory of the thing machine that represents a core vocabulary capable of providing an application.

[0022] BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the invention. The drawings illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. [Brief description of the drawings]

[0023] [Figure 1] FIG. 2 is a schematic diagram showing a primitive flow chart of how an instruction command can be responded to; [Diagram 2] FIG. 2 is a schematic diagram showing a portion of a singeing machine according to one embodiment of the present invention. [Diagram 3] FIG. 2 is a schematic diagram showing the boot process of a single machine. [Figure 4] This is a graph provided for the purpose of demonstrating the creation of the graph by the boot process performed by the boot machine. [Diagram 5] This is a graph showing the relationship in which Thing B exists separately from Thing A. [Figure 6] 1 is a graph showing the thing:sttia relationship. [Figure 7] 1 is a graph showing that a thing that has a relationship to an executable action is classified as a thing:verb using the thing:is-a relationship. [Figure 8] A namespace is a graph that supports classification where things are classified as thing:namespace, and thing:namespace is thing:class. [Figure 9] 1 is a graph showing that a thing supports classification as thing:context. [Figure 10] FIG. 2 is a schematic diagram illustrating an exemplary binding of an http URI to a thing. [Figure 11] 1 is a graph showing a thing:graph in which blank nodes represent satisfied claims, and claims may have references to thing:objects. [Figure 12] 1 is a graph showing that thing:assertion asserts that thing:subject has a value that is numeric, and therefore thing:object is not required. [Figure 13] This is a graph showing a case where a thing:assertion asserts that the value of the thing:subject is less than the value of the thing:object. [Figure 14] 1 is an example of a graph with connectors. [Figure 15] 1 is a flow chart illustrating the minimum runtime steps performed by a singing machine. [Figure 16] Let P(TM(i)) be a thing:graph such that P(TM(parse)) is the action of P, and parsing an XML document produces a thing:graph such that the following assertion is true: there is a thing with name equal to core:print, thus producing a thing:graph with a thing with name equal to "message" and value equal to "Hello, World". [Figure 17] Let P(TM(config)) be the graph such that P(TM(config)) acts on G.id (shown as a blank node) such that G.request is the thing qualified by the request namespace thing, i.e., G.urr. [Figure 18] 1 is a graph showing the my:configure version of P(TM(config)) acting on the thing identified by the URI request:statement. [Figure 19] A directed graph showing that a thing named x is a predecessor of a thing named y, and y is a successor of a thing named x, and the predicate is a thing such that there is a relationship denoted as thing:sttia. [Figure 20] It is a directed graph indicating that a thing named x is a predecessor of a thing named z, and the predicate is "such that there is an instance", denoted as thing:sttiai. [Figure 21] This is a directed graph interpreted in English. [Figure 22] This is a directed graph showing that the thing named x is a thing:table. [Figure 23] This is a directed graph that shows how many things have relationships to one thing. [Figure 24] This is a directed graph showing a thing named "x" that is a member of a class of things named "c". [Diagram 25] This is a directed graph showing the relationships indicating that the name of a thing named "x" is a member of the class of things named "b". [Figure 26] This is a directed graph showing the relationships indicating that the value of a thing named "x" is a member of a class of things named "c". [Figure 27] 1 is a directed graph showing that a context includes a request, a response, and a local namespace. [Figure 28] This is a verb graph showing that the classification defaults to request:class="thing:thing". [Figure 29] This is a verb graph that corresponds to the classification that defaults to request:class="thing:alarm". [Diagram 30] 1 is a graph showing that G.request(P(TM(i))) indicates that P(TM(i)) can act on things that are qualified in the request namespace. [Diagram 31] This is a graph showing that G.request(P(TM(i))) indicates that P(TM(i)) can act on a thing named contact that is qualified by a thing named statement that is qualified in the request namespace. [Diagram 32]A graph showing that an example G(P(TM(i))) is a rooted directed thing:graph that contains a G.request(P(TM(i))) subgraph and a G.urr(P(TM(i))) subgraph that indicates how P(TM(perform)) should request P(TM(i)) to perform its action. [Diagram 33] FIG. 1 is a schematic diagram showing a tuning machine as a general-purpose tuning machine. [Diagram 34] FIG. 1 is a schematic diagram showing a Singing Machine as an adaptive neural bot. [Diagram 35] Graph showing that during initialization, P(TM(thing)) allocates and initializes a thing with name equal to the monad as the root of the thing machine's thing:graph. [Diagram 36] 1 is a graph illustrating that a context identifies a set of things that are within the scope of resolving a list consisting of one or more free variables and relations of the free variables. [Figure 37] A graph showing that a context thing is a thing:stack, through which P(TM(thing)) can algorithmically push things onto the stack or push things off the stack, thus changing the context. [Figure 38] 1 is a graph showing that a thing having a representation of a reference to an executable action is classified as an active thing. [Figure 39] 13 is a graph showing that G(P(TM(i))) can include additional thing information, such as a thing description including responses from the execution of P(TM(i)). [Diagram 40] 1 is a G(P(TM(Thing.set))) graph corresponding to the P(TM(Thing.set)) procedure of setting a thing in non-transient memory. [Diagram 41] List request:uri, the G(P(TM(thing.get))) graph corresponding to the P(TM(Thing.get) procedure that obtains a representation of a thing given a non-transient memory. [Diagram 42] This is the G(P(TM(thing.unset))) graph corresponding to the P(TM(Thing.unset) procedure that unsets a representation of a thing from non-transient memory. [Diagram 43] This is a graph showing that G.request indicates that an operation can be performed on a request:statement that is a thing:statement. [Diagram 44] This is a G.request subgraph showing that we can perform operations on request: using the thing:listing. [Diagram 45] 1 is a graph showing P(TM(thing)) algorithmically interacting with P(TM(eval)). [Diagram 46] 1 is a graph showing that the value of the thing identified by the list request:stream is the stream to be analyzed. [Figure 47] 1 is an exemplary graph showing a parsed example XML fragment. [Figure 48] This is a graph showing that the value of the thing given by the request:input listing is the input to analyze. [Figure 49] The G(P(TM(request))) graph is shown. [Figure 50] The G.request subgraph that indicates to Sing that it can act on P(TM(bind)). [Figure 51] A thing:graph that is interpreted as an assertion describing the membership requirements of things for binding as members of the ImageObject class. [Figure 52] An unbound thing:graph given by the list local:object. [Diagram 53] This is a thing:graph that indicates a request to combine the local:object thing:graph with the schema:ImageObject thing. [Figure 54] This is an assertion that describes what it means for a thing to be classified as a broadcast service. [Figure 55] This is a G.request subgraph showing that the P(TM(perform)) action acts on the request:statement. [Figure 56] This is a graph showing that P(TM(task.set)) interacts with P(TM(thing)) to algorithmically operate on the things identified by the list request:statement.task, which is a list of things whose values ​​should be set as thing.task. [Figure 57] 1 is a graph showing P(TM(thing)), P(TM(eval)), and P(TM(task.perform)) interacting with P(TM(perform)). [Figure 58] 1 is a graph showing request:statement.listing where P(TM(format)) identifies a thing with a list value representing a thing:graph to format. [Figure 59] 1 is a graph showing that a URI qualifies a domain qualifier, a path qualifier, and a request qualifier, which qualifies a header qualifier. [Figure 60] FIG. 13 is a diagram of a generated HTTP Get Method request. [Figure 61] FIG. 13 is a diagram of the response received by P(TM(http.get)). [Figure 62] A set of thing:graphs generated from parsing the response and interacting with P(TM(thing)). [Figure 63] 13 is a graph showing P(TM(parse.html)) operating on the request:content thing whose value is a list representing the thing whose value is the HTML content to parse. [Figure 64] FIG. 1 is a diagram of exemplary microdata in HTML content. [Figure 65] A thing:graph representing microdata from P(TM(thing)) that interacts with P(TM(parse.html)) and provides behavior to parse the content. [Figure 66] We denote the P(TM) parsing content, expressed in the singe language, that describes the desired configuration of P(TM). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] Detailed Description The present system and method provide novel improvements to computer functions and capabilities, and further provide a definition of a computer, referred to herein as a thing machine.

[0025] A thing that describes the actions that can be performed can be expressed in terms of a Turing machine, which is a mathematical model of a virtual computer that can execute procedures to determine a set of results from a set of input variables.

[0026] TM(i), for i=(1,n), is a computer that can take a set of inputs, execute procedural actions P(TM(i)), and produce a set of outputs.

[0027] There can be any number of such machines, with each P(TM(i)) performing procedural operations and potentially producing an output. The output of a first P(TM(i)) can be the input of a second P(TM(i)), and often a set of P(TM(i)) can be running in parallel.

[0028] These actions can be assigned meaningful names, similar to naming verbs such as speak, listen, evaluate, and respond. By adding an action verb action, a machine can be asked to perform a specific named action. Some machines, such as the Amazon Echo or Apple Siri, can respond to voice commands in this way: Alexa, reorder paper towels. Siri, what time is it. In each example, we are asking the machine to perform some action, such as ordering an item or answering a question.

[0029] To fulfill a request, the machine must first evaluate what is being requested. In some ways, this is similar to asking a second grader to subtract 7 from 21. The sequence involves parsing the words into thoughts using English listening vocabulary, evaluating what the thoughts mean, selecting an action, performing the action, and using English speaking vocabulary to communicate a response. Alternatively, the second grader could shrug and respond, "I don't know."

[0030] Note also that asking a machine to perform some action does not imply that it will perform the same action for each person who requests it. For example, consider a URL typed into a web browser, such as http: / / www.thinglanguage.com / v1 / index.html. By typing this URL, you are essentially asking the browser to retrieve and display the thing identified by the URL. Both the identifier and the corresponding resource are things.

[0031] Two people asking their browsers to retrieve and display the same URL can have two different results, even though they both entered the same URL. In one case, the content may be specific to the individual. In another, the HTTP request headers may contain state information that the web server uses to construct the resource content. It is important to realize that while the URL may identify something, what is displayed will be different.

[0032] The Thing Machine provides a unique way of managing, interpreting received requests and modifying the Thing Machine's vocabulary based on the boot Thing Machine vocabulary that adapts upon interaction with the Thing Machine, the vocabulary providing the basis upon which the Thing Machine can perform actions. As a result, the Thing Machine is able to interpret, act on and adapt received requests with increasing interpretation and action capabilities as set forth herein. Received requests, interactions and responses to the Thing Machine's requests are performed based on categorization of the thing as either an action thing, which is a verb that is an action, or a thing that can be acted upon by a thing, which is an action thing (also referred to herein as a non-action thing).

[0033] As mentioned above, at a thing's singularity, a thing can represent an executable action or a thing on which an executable action can act. As described and illustrated herein, the thing machine organizes things as a thing:graph, where the nodes of the graph represent things, and the arcs in the thing:graph represent variable relationships between things.

[0034] A thing that represents an action that can be performed is referred to herein as a thing:verb, and a collection of thing:verbs is a verb vocabulary thing. A thing on which a verb vocabulary and verb actions can act is a vocabulary thing. In essence, with a minimal vocabulary, the present system and method use universal quantification to assert: Given a thing that is a request received by a thing machine, the thing machine parses the request, then evaluates the request in the context of the thing machine's available vocabulary to select an appropriate verb and perform the verb's corresponding action. The execution of the action generates a set of things that represent a response. This generalization allows the response for certain actions that do not generate a grammatical response to be the empty set of things. Sometimes, such as in the case of a shutdown verb, the observation of the action being performed is a sufficient response.

[0035] Overview The following provides an overview of the ThingMachine and associated vocabulary and includes three main parts. 1. The Thing Graph Data Model description that describes Things as having non-mutable components that contain relation sets that contain mutable relations between Things. 2. Architectural Overview,Providing a high-level overview of the Thing Machine architecture. 3. The Sing language section, which provides an introduction to writing documents in the Sing language.

[0036] Singing Machine Structure Figure 2 is a schematic diagram illustrating portions of a thing machine 100 according to one embodiment of the present invention. As shown in Figure 2, thing machine 100 includes memory 102, processor 104, and non-transitory secondary storage device 106, each of which are communicatively coupled via a local bus or local interface 108 that enables communication within thing machine 100.

[0037] The memory 102 stores therein software 120 that defines the functionality described herein. The thing machine 100 also includes input / output (I / O) devices 110 (or peripherals). The local interface 108 can be, by way of example and not limitation, one or more buses or other wired or wireless connections as known in the art. The local interface 108 may have additional elements, such as controller buffers (caches), drivers, repeaters, and receivers, omitted for simplicity, to enable communication. Additionally, the local interface 108 may include address, control, and / or data connections to enable appropriate communication between the above components.

[0038] Processor 104 is a hardware device that executes software, particularly software stored in memory 102. Processor 104 can be any custom-made or commercially available single-core or multi-core processor, a central processing unit (CPU), a coprocessor among several processors associated with the processing machine 100, a semiconductor-based microprocessor (in the form of a microchip or chipset), a microprocessor, or generally any device that executes software instructions.

[0039] The memory 102 may include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (e.g., ROM, hard drives, tape, CD-ROM, etc.). Additionally, the memory 102 may incorporate electronic, magnetic, optical, and / or other types of storage media. It is noted that the memory 102 may have a distributed architecture, in which various components are located remotely from one another, but may be accessed by the processor 104.

[0040] Software 120 defines the functions performed by the thing machine in accordance with the present invention. Software 120 in memory 102 may include one or more separate programs, each of which includes an ordered list of executable instructions that implement the logical functions of thing machine 100, as described below. By way of example, software 120 may define a parser 122, an evaluator 124, an executor 126, and a formatter 128, the functions of which are described herein.

[0041] Memory 102 may include an operating system (O / S) 122. The operating system essentially controls the execution of programs within the thing machine 100 and provides scheduling, input / output control, file and data management, memory management, and communication control and related services.

[0042] The I / O devices 110 may include input devices, such as, by way of example and not limitation, a keyboard, mouse, scanner, microphone, etc. Additionally, the I / O devices 110 may also include output devices, such as, by way of example and not limitation, a printer, display, etc. Finally, the I / O devices 110 may further include devices that communicate via both input and output, such as, by way of example and not limitation, a modulator / demodulator (a modem for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephone interface, a bridge, a router, or other devices.

[0043] When the system, the thing machine 100, is in operation, the processor 104 is configured to execute software 120 stored in the memory 102, to exchange data with the memory 102, and generally to control the operation of the thing machine 100 in accordance with the software 120, as described above.

[0044] When the functionality of the thing machine 100 is in operation, the processor 104 is configured to execute software 120 stored within the memory 102, to communicate data with the memory 102, and to generally control the operation of the thing machine 100 in accordance with the software 120, as described above. The operating system 122 is read by the processor 104, possibly buffered within the processor 104, and then executed.

[0045] It should be noted that when the thing machine 100 is implemented in software 120, the instructions implementing the thing machine 100 can be stored on any computer-readable medium used by or in connection with any computer-related device, system, or method. Such a computer-readable medium may correspond to one or both of memory 102 or storage device 106 in some embodiments. In the context of this document, a computer-readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program used by or in connection with a computer-related device, system, or method. The instructions implementing the system can be embodied in any computer-readable medium used by or in connection with a processor or other such instruction execution system, apparatus, or device. Although the processor 104 is mentioned as an example, such an instruction execution system, apparatus, or device can in some embodiments be any computer-based system, processor-containing system, or other system that can fetch instructions from and execute instructions from an instruction execution system, apparatus, or device. In the context of this document, a "computer-readable medium" can be any means that can store, communicate, propagate, or transport a program for use by or in connection with a processor or other such instruction execution system, apparatus, or device.

[0046] Such computer-readable medium can be, for example and not by way of limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (non-exhaustive list) of computer-readable medium include: an electrical connection with one or more wires (electronic), a portable computer disk (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or flash memory) (electronic), an optical fiber (optical), and a portable compact disk read-only memory (CD-ROM) (optical). Note that the computer-readable medium can even be paper or another suitable medium on which the program is printed, because the program can be captured electronically, for example, via optical scanning of the paper or other medium, and then compiled, interpreted, or otherwise processed as appropriate, if necessary, and then stored in the computer memory.

[0047] In alternative embodiments in which the thing machine 100 is implemented in hardware, the thing machine 100 may be implemented using any or a combination of the following technologies, each of which is well known in the art: discrete logic circuits having logic gates that perform logical functions on data signals, application specific integrated circuits (ASICs) having appropriate combinatorial logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0048] According to a first exemplary embodiment of the present invention, initially, memory 102 contains a thing machine procedure P(TM) (which is an executable procedure) that is comprised of a set of thing machine procedures P(TM(i)). Those skilled in the art will appreciate that multiple P(TM(i)) may be implemented in a single computing device, such as, but not limited to, a Dell Latitude 15 3000 series laptop running Windows 10; using a system on a chip, such as a Raspberry Pi 3; using multiple computing components in a single machine; or using multiple separate, separate machines that may communicate directly or indirectly. The thing machine may be implemented using a plug and play architecture, such as, but not limited to, that defined in U.S. Patent No. 6,363,437, Plug and Play I2C slave, which is incorporated herein by reference in its entirety.

[0049] A first P(TM) composed of multiple P(TM(i)) can be configured as P(TM(i)) of a second P(TM).

[0050] A Thing Machine (TM) is a procedure P(TM) that can operate on a set of things (e.g., inputs such as requests), perform an action, and generate a set of things (e.g., outputs such as generated responses). According to the Turing model of computability and that a universal Turing machine can simulate a Turing machine, hypothetically,

number

number

[0051] Each P(TM(i)) is an algorithmic implementation of a model or a component of a model expressed in executable machine code that performs a distinct sequence of steps, and each P(TM(i)) is executable by P(TM(perform)). Instead of numbers, in accordance with the present invention, the thing machine uses words to describe the type of action to take on a given P(TM(i)). P(TM(perform)) is defined in more detail herein.

[0052] A model can be a representation of a selected part of the world, such as a model of a phenomenon, a model of data, a model of a theory, or a model of a problem statement in a conversational domain (such as an application modeled to solve a business problem), where a scientific model can be a representation of these at the same time, so the above models are not exhaustive and models can be expressed in terms of the singular models disclosed in this specification (see https: / / plato.stanford.edu / entries / models-science / regarding "Models").

[0053] A given TM(i) having a procedure P, expressed as P(TM(i)), need not be primarily a digital processor operation, but may use a digital processor to produce mechanical, electrical, electromagnetic wave, biological, chemical generation or reception of pressure waves, or generation or reception of electromagnetic radiation.

[0054] As an example, a processor action may cause a voltage to be applied to the electrical interface, allowing a motor action to propel the thing machine forward or reverse. Such action may continue until a second P(TM(i)) processor action resets such voltage. Thus, the thing machine continues to perform mechanical actions while allowing P(TM) to respond to other thing:statements.

[0055] As a further example, P(TM(i)) may use an input-driven recombinase to perform operations that interact with a recombinase-based state machine (RSM) that manipulates a DNA register composed of overlapping and orthogonal pairs of recombinase recognition sites, and thus may query or sequence state information encoded in the RSM.

[0056] The P(TM) memory contains a minimum set of P(TM(i)) required for initialization, as described in detail in the section of this description entitled Booting. In summary, according to a first exemplary embodiment of the present invention, P(TM) contains the following P(TM(i)): P(TM(boot)), P(TM(thing)), P(TM(parse)), P(TM(eval)), P(TM(perform)), and P(TM(configure)). The main logic of P(TM) is to execute P(TM(boot)) and then stop. Initially, it should be noted that the P(TM) memory may provide additional or fewer P(TM(i)).

[0057] The thing machine is booted with a limited, self-configurable boot vocabulary of things. The P(TM(thing)) operation organizes things and variable relationships between things as a thing:graph. Some things represent executable actions. Execution of executable actions can act on things. The P(TM(i)) operation can request P(TM(thing)) to perform actions related to the supervision of things, such as, but not limited to, setting, getting, and unsetting things and / or variable relationships between things. Things can be modified by getting and setting things. In addition, things can be unset and set. In that regard, the thing graph can be seen as the thing machine's vocabulary, which represents the thing machine's knowledge base (the actions that the thing machine knows how to perform and the things that the actions can act on).

[0058] It should be noted that within the scope of this disclosure, the term "interact with" refers to P(TM(i)) causing associated machine code to be executed. For example, if A "interacts with" B, A causes B to execute associated machine code.

[0059] The P(TM(input)) and P(TM(output)) operations interact with an electromagnetic device to provide communication with P(TM). The operations interact with P(TM(thing)) such that inbound content is a request thing and outbound content is a response thing.

[0060] The P(TM(parse)) operation parses the content thing and interacts with P(TM(thing)) to create a thing:graph that represents the statement. In a first exemplary embodiment of a machine acting as an interpreter, the thing:graph is an executable thing:graph. In a second exemplary embodiment of a thing machine, the P(TM(eval)) operation interacts with P(TM(thing)) to evaluate the thing:graph in the context of an accessible vocabulary to generate an executable thing:graph. Note that the algorithmic steps of P(TM(input)) and P(TM(parse)) can be combined into a single procedure given by an appropriate P(TM(i)), such as P(TM(parse.input)).

[0061] A P(TM(perfrom)) operation interacts with P(TM(thing)) to perform the executable operations of the thing within the context of the thing that can perform the operation.

[0062] The P(TM(format)) operation interacts with P(TM(thing)) to format the response namespace thing as an outbound content response thing that the P(TM(output)) operation outputs. Note that the algorithmic steps of P(TM(format)) and P(TM(output)) can be combined into a single procedure given by the appropriate P(TM(i)), such as P(TM(format.output)).

[0063] The P(TM(configure)) operation interacts with P(TM(thing)) to configure P(TM(i)) as an executable thing, also called an active thing or verb. This allows the vocabulary of executable operations to be updated. The things that the machine can perform at this point can be added, removed, or changed in range of complexity. Note that P(TM(i)) provides algorithmic operations, where i denotes a name that represents the operation. The operations could be neural net classifier operations, electronic trading operations, or any other such algorithmic operations that can be put into action.

[0064] boot Before using the thing machine 100, the thing machine 100 may perform a boot process to acclimate and further adapt to its environment and the source of requests received.

[0065] Each time the thing machine is powered up, the P(TM(boot)) action interacts with P(TM(thing)) to self-configure a thing:graph, which represents a vocabulary consisting of a set of thing:verbs, each of which represents an action that the P(TM(perform)) action can make perform, and things that the actions can act on, to bootstrap the machine with things that represent P(TM)'s prior knowledge, such as its last known state before shutdown. If we define experience as the action of the thing machine (P(TM(thing)) oversees the thing:graph) that is doing something and causing things to occur, then we can say that the thing machine gains experience (things, or knowledge represented as things, that represent actions that things can perform) as a result of performing things.

[0066] Using this vocabulary, the thing machine constructs a core vocabulary that provides the foundation on which applications can run. Thus, a performance of P(TM(i)) can interact with P(TM(thing)) to modify the thing:graph, and these modifications can be thought of as a posteriori knowledge (a thing learning from experience).

[0067] Operations can traverse the thing:graph, format content, and interact with secondary storage to persist the thing:graph information, which can then be retrieved and used by operations that reconstruct the thing:graph.

[0068] In one embodiment, the core vocabulary can be constructed to contain a predetermined set of things, where the vocabulary is of a finite, predetermined size and scope. In a second embodiment, a set of things in the vocabulary is dynamically supervised by a thing machine, where things are set (learned and added to the thing:graph) and other things are unset (forgotten and removed from the thing:graph).

[0069] The Thing Machine organizes things as graphs. One graph, called the context graph, contains things that represent namespaces. A namespace is a named graph used to represent a conceptual grouping of things, such as a request, a response, a set of tasks, a service, a verb vocabulary, or an application dictionary. A namespace vocabulary can be seen as a form of ontology. However, several namespaces that use discrete vocabularies may share ontological commitments in parts of the vocabulary.

[0070] In graph self-construction, P(TM(boot)) requests P(TM(thing)) to construct a thing that represents a verb action, where the thing has a representation of references to executable actions that P(TM(perform)) can perform. Exemplary verb actions include, but are not limited to, parsing, evaluating, executing, and constructing. Collectively, the things are called a vocabulary, and the graph of the things is the boot vocabulary. The thing machine's boot process self-constructs the thing machine's limited vocabulary to represent the machine's prior knowledge (the initial things of the vocabulary). The limited vocabulary includes verbs and things that the verbs can act on. According to a first exemplary embodiment of the present invention, the thing machine's basic verb vocabulary includes at least the verbs "input", "output", "parse", "evaluate", "execute", and "construct". The Thing Machine's procedures associated with each verb are respectfully called P(TM(parse)), P(TM(eval)), P(TM(perform)), and P(TM(configure)). As described in more detail below, this allows the Thing Machine to evaluate requests in the context of self-constructed thing:verbs, and to perform construction operations that add additional verbs to its verb vocabulary. Using this model, the Thing Machine's verb vocabulary is dynamically configurable, and can grow and shrink in size and scope as needed.

[0071] The process of self-organization involves not only receiving a limited vocabulary, but also creating at least one thing:graph for each verb. In particular, verbs in a thing:graph are nodes as well as non-verbs (both are things), and arcs in a thing:graph represent variable relationships between things. Thus, a thing:graph defines the relationships between the things that follow.

[0072] A P(TM(thing)) operation organizes things and variable relationships between things as a thing:graph. Some things represent actions, occurrences, or states of existence, and other things are things on which the operation can act. The thing machine is booted with a limited, self-constituting boot vocabulary of things. Using the boot vocabulary, the thing machine constructs prior knowledge, including a core vocabulary composed of things.

[0073] The P(TM(input)) operation interacts with an electromagnetic device to provide communication to P(TM). An embodiment of the present invention may combine P(TM(input)) with P(TM(parse)). The operation interacts with P(TM(thing)) such that inbound content is a requested thing that can be parsed by the parse operation.

[0074] The P(TM(output)) operation is an optional operation that interacts with an electromagnetic device to provide communication from P(TM).

[0075] The P(TM(parse)) action parses the content thing and interacts with P(TM(thing)) to create a thing:graph that represents the statement. In a simple machine acting as an interpreter, the thing:graph is an executable thing:graph. In an adaptive thing machine, P(TM(eval)) interacts with P(TM(thing)) to evaluate the thing:graph in the context of an accessible vocabulary, producing an executable thing:graph. Note that P(TM(input)) and P(TM(parse)) can be combined into a single action given by an appropriate P(TM(i)), such as P(TM(parse.input)).

[0076] The P(TM(perform)) operation interacts with P(TM(thing)) to perform the thing's operation within the context of the thing that can perform the operation.

[0077] The P(TM(configure)) operation interacts with P(TM(thing)) to configure P(TM(i)) as an executable thing. This allows the vocabulary of executable operations to be updated. The things that the machine can execute at this point can be added, removed, or changed in complexity. Note that P(TM(i)) provides algorithmic operations, with i denoting the name that represents the operation. The operations could be neural net classifier operations, electronic trading operations, or any other such algorithmic operations that can be put into execution.

[0078] With reference to the boot process and the schematic diagram of Figure 3, when the thing machine 100 boots, P(TM(boot)) requests P(TM(thing)) to create a boot vocabulary for the thing machine (block 202). P(TM(thing)) receives the request and creates a thing (for illustrative purposes, called "boot:") that represents the boot vocabulary (block 204). The creation of the thing is performed by P(TM(thing)) initializing a unit of memory to the size of the thing (i.e., the thing that boot:) identifies as a thing in the boot vocabulary.

[0079] Singgraph Data Model Figure 4 is a graph provided for the purpose of demonstrating the creation of a graph by the boot process performed by the Thing Machine 100. This section defines an abstract syntax that serves to link all Thing-based languages, specifications, and reference implementations based on RDF. RDF is a framework for representing information on the Web (W3C, 2014). An RDF graph is a set of triples, each triple consisting of a subject, predicate, and object, as shown in Figure 4. RDF provides three types of nodes. A node can be an IRI (see RFC3987), a character, or a blank node. An IRI or a character points to something in the world and is called a resource.

[0080] An RDF thing graph is an RDF graph for a thing. An RDF thing graph describes the immutable components of a thing. The components are immutable, but the values ​​of the components are mutable. Some things are active things that have actions that can be performed, often called verbs. Other things are things on which verb actions can act. Things can represent RDF resources, concepts, facts, ideas, entities, objects, instances, events, occurrences, devices, sensors, services, tasks, services, users, web resources, etc.

[0081] A thing is composed of non-mutable components. A thing is supervised by P(TM(thing)), which has knowledge of the non-mutable components. A first exemplary non-mutable component of a thing is an identifier used to distinguish one thing from another in the conversation domain, although there can be things with duplicate names, such as things with duplicate names that are members of a thing representing a list.

[0082] A second exemplary non-mutable component of a Thing is a value. In one embodiment, the value is an RDF character defined in the RDF 1.1 specification. Those skilled in the art will be familiar with the RDF 1.1 specification, which is incorporated herein by reference in its entirety. In addition, those skilled in the art may use alternative value representations defined by alternative specifications. Note that the value of a non-mutable component value of a Thing may be empty.

[0083] A third exemplary non-mutable component of a Thing is a relationship set. If a Thing has an empty relationship set, then the Thing represents a null graph. A relationship set is a set of relationships that hold between a first Thing and a second Thing. The primary relationship is one of an association. An association can be in the form of a composition or an aggregation. If Thing A is composed of Thing B, then the relationship is immutable. If Thing A is a collection that contains Thing B, then the relationship is mutable. Here, as an example, Thing B can exist independently of Thing A, as shown in FIG. 5. As stated, a Thing is supervised by P(TM(thing)), which has knowledge of the non-mutable components.

[0084] The first example relationship is the thing:sttia relationship, which uses existential quantification to indicate: there is this subject Thing such that there is an object Thing. The relationship is mutable. This is shown in Figure 6.

[0085] An object thing can represent a collection of things, such as a list of things or a set of things. Relationships can be expressed using instance modifiers like: there is this subject THING such that there is an instance of an object THING. An instance of a thing can have different meanings depending on the classification of the thing. In some cases, an instance can be a member or an occurrence of something.

[0086] The thing:is-a relationship expresses that a first thing is a type of a second thing. This is explained further herein in the section called Attributes as Metadata. In a general sense, the thing:is-a relationship allows for the classification of things.

[0087] The thing:depends-on relationship indicates that the subject thing has a dependency on the object thing. Additional relationships, such as those from UML, can be added to the RDF thing graph data model. These include association, collection, directed association, composition, reflexive association, inheritance, manifold, and realization.

[0088] Identifiers and Lists A list is a representation of a reference to a thing. A list may be an unbound name, such as an identifier, or it may be represented to convey a relationship between two or more things. The list "this" is a simple identifier indicating that we are referring to the thing whose name equals "this". The list "this.that" can indicate that there is a thing whose name equals "this", such that there is a thing whose name equals "that". The exact interpretation of a list depends on the namespace to which the list is bound, which is covered in more detail in the section on URIs (see RFC3986), as described below.

[0089] Attributes as Metadata An attribute describes an inherent characteristic or quality of a thing. Attributes are expressed as metadata: thing:metadata is a thing that identifies the type of the attribute, and the value of the thing describes the value of the attribute.

[0090] Attributes are identified as thing:metadata and can be used in triples following one another. As an example, the thing:class attribute is used to indicate a classification of a thing. A class is a set of things that, at a given instant in time, satisfy membership criteria that specify what is required for a thing to be a member of the class. Intent is a time-dependent criterion. An extension at a given instant in time is a list of all the members at that time.

[0091] Attributes may describe states. For example, a Thing can be declared without indicating a classification, and a bind operation can be performed on an "unbound" Thing to bind the "unbound" Thing to something the bind operation can recognize, even if it is bound as an "unknown" Thing. The bind operation transitions a Thing from the unbound state to the bound state. A bound Thing may or may not be able to be found. A bound Thing that is found indicates that the bind operation was able to bind the Thing to something the bind operation understands. A bound Thing that is not found indicates that a bind operation was applied to a Thing, but the Thing was not something the bind operation is able to understand.

[0092] Active Things A thing having an expression of reference to a particular operation is classified as an active thing. In this context, an executable operation is an operation that a machine can cause to be performed to achieve some result, which may be primarily computational, electrical, chemical, optical, biological, mechanical, electromagnetic, or a combination thereof.

[0093] An active thing in this document is often referred to as a thing:verb, in the sense that a verb is a noun that describes an action, and an active thing describes an action. Thus, the name of an active thing is a verb that describes an action that an identifier can perform.

[0094] In one embodiment that supports classification, things that have a relationship to an executable action are classified as thing:verb using the thing:is-a relationship, as shown in FIG.

[0095] A verb can act on a set of things. The things that can be acted on may be specified explicitly in the RDF thing graph, or implicitly by a taxonomy. Quantifiers can be used to restrict the scope of things in the conversation domain to those things that the verb action can act on.

[0096] Namespace A namespace is a thing that represents a named graph of things that are logically related in some way, even if they are related only by being members of the same namespace. The graph contains things and relationships between things. In a graph that supports classification, as shown in Figure 8, a namespace thing is classified as a thing:namespace, and a thing:namespace is a thing:class.

[0097] context A context is a thing that quantifies a set of namespaces that have a current scope. In a graph that supports classification, a thing is classified as a thing:context, as shown in Figure 9.

[0098] A context allows a set of namespaces to have current scope to use when dereferencing IRIs that represent Things. For example, request:statement is an IRI that can be resolved relative to a context. In English, this is expressed as:There is namespace where the name is equal to request, such that, there is a Thing where the name is equal to statement.

[0099] URI A URI identifies a resource, and a Thing is the representation of that resource in a Thing machine. A Thing has either an executable action or a Thing that the executable action can act on. A generalized form of URI is: scheme:scheme specific part is given as:

[0100] In the thing machine, a scheme is interpreted as a reference to a namespace thing whose name follows the naming rules for URI schemes, as shown below. This has the advantage that an RDF thing graph can be used to represent existing scheme names. A namespace name consists of a sequence of characters starting with a letter followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-") - RFC3986.

[0101] All permanent URI schemes published by the Internet Assigned Numbers Authority are reserved namespace names. Modeling of things in a reserved namespace should conform to the semantics of the published RFC for that namespace. For example, to model things in the news: and nntp: namespaces, RFC5538 should be consulted. The list of published URI schemes is maintained by IANA, http: / / www.iana.org / assignments / uri-schemes / uri-schemes.xhtml Available online at:

[0102] The "URN" namespace is a reserved namespace whose namespace-specific parts are to be interpreted as defined by the corresponding RFC document published for that URN namespace. The list of published URNs is maintained by IANA, http: / / www.iana.org / assignments / urn-namespaces / urn-namespaces.xhtml Available online at:

[0103] The namespace-specific part of the list is interpreted according to the namespace (scheme) specification.

[0104] A parser for the generic URI syntax can parse any URI reference into its main components. Once the scheme has been identified, further scheme-specific parsing can be performed on the components. In other words, the URI generic syntax is a superset of the syntax of all URI schemes.

[0105] However, the http:, https:, and file: namespaces use the " / " character delimiter, so the reference: http: / / www.THINGlanguage.com / request becomes: There is a THING:NAMESPACE with name equal to "http", which has a thing with name equal to "www.THINGlanguage.com", which has a thing with name equal to "request". is interpreted as:

[0106] The mailto namespace interprets references according to RFC6068. For example, the reference:mailto:info@thinglanguage.com: There is a THING:NAMESPACE with name equal to "mailto", and in it there is a thing with name equal to info@THINGlanguage.com. is interpreted as:

[0107] You can also model the THINGS:scheme supported on OSX and IOS. A THINGS:URI is given as THINGS:command?parameter1=value1¶meter2…. This means There is a THING:NAMESPACE with name equal to "THINGS", which has a thing with name equal to "command", which has an instance of a thing with name equal to "parameter1" and value equal to "value1", which has an instance of a thing with name equal to "parameter2". is interpreted as:

[0108] The name of a namespace thing follows the naming requirements of an IRI scheme (see RFC3987). It serves as a way to bind a URI (which is a form of IRI and is described in RFC3986) to a thing. URI scheme names are bound to namespace things. For example, all http: URIs are bound in the http:namespace thing. An example binding of http URIs to things is shown in Figure 10.

[0109] Satisfaction Claims A basic assertion is a thing:assertion that represents a satisfied claim, asserting that a given claim is true. In the thing graph model, assertions are things rather than directed edge labels. With reference to Figure 11, in a thing:graph, blank nodes represent satisfied claims, and claims may have references to thing:objects.

[0110] As shown in Figure 12, thing:assertion asserts that thing:subject has a value that is numeric, and therefore thing:object is not required.

[0111] As shown in Figure 13, thing:assertion asserts that the value of thing:subject is less than the value of thing:object.

[0112] The truth of a satisfaction claim depends on the computational procedure that corresponds to the claim. In that respect, a satisfaction claim is an active thing with a corresponding trhing:graph that describes the things on which the action can act.

[0113] Exemplary satisfied claims include, without limitation, those set forth in Table 1 below.

[0114] [Table 1]

[0115] The "is" part of a simple predicate can be followed by "not" to indicate the negation of the predicate, e.g., thing:is-not-equal-to. The negation of thing:match is specified as thing:does-not-match.

[0116] connector Logical connectors are used to connect two satisfaction claims. Exemplary connectors include, without limitation, and, or, not, implies, and iff. Similar to satisfaction claims, logical connectors are represented as things rather than directed edge labels. Logical connector things are active things. An example of a graph with connectors is provided in FIG. 14.

[0117] Examples of simple connectors include, but are not limited to, the following as shown by Table 2:

[0118] [Table 2]

[0119] In a procedural graph, indeed, satisfaction claims evaluate to true (satisfied) or false (unsatisfied), but in a declarative graph, satisfaction claims can be expanded to include a set of things over which the claims span.

[0120] Graph Type A thing graph has a procedural nature if it describes how to do something. For example, a graph that sets the value of a thing is a procedural statement, since it is a sequence of statements that describe the actions required to perform a task.

[0121] A singe graph is declarative if it is a statement that represents a declaration. HTML is an example of a declarative statement. The HTML source code describes the desired layout of a document, and an HTML rendering engine processes the HTML source code to perform the actual layout.

[0122] A single graph is object oriented if it describes objects and methods. As an example, a graph showing objects and the methods to set, get and unset the objects is object oriented.

[0123] A singe graph is an event-driven graph if events, such as messages or states, drive the evaluation of the graph. A singe graph is a finite state graph if it represents states and transitions between states, for use in a finite state machine.

[0124] The singe graph may be a combination of one or more of the above types of graphs, such as Harrell's state diagram, XML state diagram, or UML state diagram. D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach. McGraw-Hill, 1998. (See http: / / www.wisdom.weizmann.ac.il / ?dharel / reactive#systems.html)

[0125] A thing machine procedure P(TM(thing)), expressed in executable machine code, provides operations in non-transient memory that oversee things and relationships between things. A thing, which has a representation of a reference to an executable operation, is a verb. A thing machine procedure P(TM(perform)), expressed in executable machine code, provides operations that interact with P(TM(thing)) to obtain a reference to a verb thing and cause the verb's executable operation P(TM(i)) to be performed. The perform operation can interact with the P(TM(thing)) operation to act on the thing in non-transient memory. A thing machine procedure P(TM(configure)), expressed in executable machine code, provides operations that interact with P(TM(thing)) to configure the verb thing. Thus, problem statements can be written and solutions constructed in terms of things that a thing machine can perform as operations and things on which the operations can act.

[0126] 15 is a flow chart 250 illustrating the minimum runtime steps executed by a processing machine. Any process description in a flow chart should be understood as representing a module, segment, portion of code, or step that includes one or more instructions that implement a particular logical function in the process, and it should be noted that alternative embodiments that may perform functions out of the order shown or discussed, including substantially simultaneously or in reverse order, depending on the functionality involved, are included within the scope of the invention, as would be understood by one of ordinary skill in the art of the invention.

[0127] In particular, note that at least the following steps are performed by the thing machine: As shown in block 252, algorithmically, P(TM(i)) operates, such as by analyzing inputs, interacting with sensors, or requesting the thing machine to perform actions, to generate a thing:graph representing statements for the thing machine to evaluate and execute actions.

[0128] This is useful for P(TM(i)) to obtain such temperature, acceleration, altitude, longitude and / or latitude, motion sensor, heat sensor, smoke sensor, or other such sensor, sensor-generated data to incrementally build a thing:statement and execute a corresponding executable thing:statement. Similarly, P(TM(i)) notified of a signal, such as an event, timer, interrupt, or alarm, can interact with P(TM(request)) to build and evaluate a thing:statement and execute a corresponding executable thing:statement so that P(TM) can respond to its receipt.

[0129] A first exemplary embodiment of such a P(TM(i)) parses an XML document to produce a thing:graph such that the following assertions are true: There is a thing with name equal to core:print, which has a thing with name equal to "message" and value equal to "Hello, World". The corresponding thing:graph is shown in Figure 16.

[0130] As shown in block 254, the P(TM(eval)) operation interacts with P(TM(thing)) to access and interact with the thing:graph and the current verb vocabulary to algorithmically select appropriate verb actions to build and populate the executable thing:graph. Note that the current verb vocabulary may be the initial verb vocabulary or may be a dynamically changed verb vocabulary.

[0131] As shown in block 256, the P(TM(perform)) operation interacts with P(TM(thing)) to obtain the executable thing:graph and cause it to be executed.

[0132] According to alternative embodiments of the invention, the thing machine may not include a P(TM(eval)) operation. In such embodiments, P(TM(parse)) interprets statements.

[0133] THING:GRAPH / Core Vocabulary Changes As mentioned above, P(TM(i)) can interact with P(TM(thing)) to set up a thing:graph. In the thing architecture, the details of input and output can be abstracted and emerged through the use of verb actions. The choice of language, grammar, syntax, and communicative actions is itself simply a thing.

[0134] Any number of languages ​​and syntaxes can be received in a P(TM(i)) input stream and parsed, so long as the P(TM(parser)) operation is capable of algorithmically parsing the elements of the grammar syntax into a thing:graph.

[0135] A language is something, more precisely described as a communicative system that includes a vocabulary and a grammar. A vocabulary is the vocabulary, i.e., the set of words or phrases, in a language. A grammar imposes rules, such as morphology, semantics, and syntax.

[0136] Actions are things that must be performed in order to communicate. Visual communication skills such as reading and observing can be used. Physical actions such as writing or signing can be used. Audio communication skills can be used. Alternatively, a Braille writing system can be used. These are all things, and because they are things, these actions can be modeled and constructed as actions that a thing machine (i.e., P(TM)) can perform.

[0137] Gestures, as a form of communication, transcend society: the meaning of a finger pointing in a certain direction, a stamp of the foot, or a smile is commonly understood. Gestures differ from sign languages ​​in the sense that sign languages ​​use established expressions and movements that have clearly defined meanings.

[0138] Like people, a Singing Machine may have a reading vocabulary, a writing vocabulary, a listening vocabulary, and a speaking vocabulary for a given language. Each of these vocabulary may be at a different level. A Singing Machine may know what a word means when it hears it due to the configured Singing, but may not be able to pronounce or write the word correctly. Similarly, a Singing Machine may read something and see a word it does not recognize. For example, the word ossify is an English verb word that means hard as a bone, but it may be one of the rarely used verbs in the English language, and therefore the modeled embodiment may not be configured into the Singing Machine's verb vocabulary.

[0139] When the Singing Machine identifies an unfamiliar word, it may attempt to interpret the meaning of the word by interacting with its syllables. The Singing Machine may be able to infer meaning if it can detect the root. As the Singing Machine learns new words and their uses, it may add these new words to a variety of vocabulary.

[0140] A multilingual Singing Machine can have different vocabulary capabilities for each language it knows. The Singing Machine can be modeled on the language instruction system of an Arabic student learning Papiamentu, Dutch, Spanish, and English at school. Each Singing Machine can develop reading, writing, listening, and speaking vocabulary at different rates and potentially with different performance in each language.

[0141] A thing machine can parse a statement according to grammar and syntax into token things and bind the token things to things in the corresponding vocabulary. Certain things can be classified immediately, while other things must look at the surrounding words to infer their meaning.

[0142] The meaning of a statement may nevertheless be ambiguous. Consider the statement: "Let's eat honey". This could mean eating honey, or it could mean that you encourage your loved one to start eating. As will be explained in detail herein, to facilitate the interpretation and management of the meaning of statements, we introduce the idea of ​​a thing-verb graph, where the start node is a verb name and the connected nodes are things on which the verb action can act.

[0143] It is important to note that execution of an action may subsequently compose a verb P(TM(i)) other than P(TM(parse)) to interact with P(TM(thing)) to create a thing:graph, which may then be evaluated to create an executable graph. Execution of an executable thing:graph may cause the action to interact with P(TM(thing)) and modify the thing:graph of the thing that P(TM(thing)) supervises. An exemplary embodiment of such a P(TM(i)) is P(TM(cofnig)), which provides actions that interact with P(TM(thing)) to compose a set of active things, where a set is one or more.

[0144] The operations of P(TM(i)) can interact with the environment to generate a thing:graph representation of the request that modifies the thing:graph overseen by P(TM(thing)). In response, P(TM(config)) interacts with P(TM(thing)) to modify the thing:graph overseen by P(TM(thing)). Thus, the operations of P(TM(config)) modify the current vocabulary, also referred to herein as the core vocabulary.

[0145] Referring to FIG. 17, P(TM(config)) operates on G.id (shown as a blank node) such that there are things qualified by the request namespace thing, namely G.request and G.urr.

[0146] The name of the G.id thing is the identifier of the verb thing that P(TM(config)) configures. G.request is a graph describing the things that execution of the verb thing can act on. The value of the G.urr thing is a URI that is interpreted as a uniform resource request requesting execution of the verb thing.

[0147] Referring to Figure 18, the my:configure version of P(TM(config)) operates on a thing identified by the URI request:statement, where thing is a vocabulary identifier (vocabulary.id), and thing is a graph ID where G.request and G.urr are. The vocabulary identifier can be used by the classifier when algorithmically selecting a set of verb things in the conversational domain that P(TM(eval)) will use to evaluate the thing:statement.

[0148] In one embodiment, P(TM(config)) can interact with a thing that represents a shared library, such as a dynamic link library, whereby said shared library is dynamically loaded into process memory and references to functions are resolved and executed to provide a set of procedures and corresponding graphs, thereby allowing multiple verb things to be configured.

[0149] In one embodiment, P(TM(config)) can algorithmically interact with P(TM(eval)) and P(TM(perform)) to evaluate and execute thing:statements that must be satisfied as prerequisites for constructing a set of verb things. The thing:statements can represent requests to check accessibility, version information, revision information, dependencies, conflicts with existing verb things, identification, authorization, authentication, security, hardware capabilities, operating system capabilities, or other such activities.

[0150] In an embodiment supporting identification, authentication, and authorization, the P(TM(config)) operation may interact with P(TM(i)) to identify, authenticate a thing:statement, and impose authorization requirements that must be met to configure the thing:statement. As an example, the thing:statement may require a digital signature along with an identity that can be authenticated to determine whether the identity is authorized to request P(TM(config)) to perform the operation. Various security models may be algorithmically enabled, which may require the use of specific hardware and P(TM(i)) configuration things, such as those disclosed in pending U.S. patent application Ser. No. 62 / 288,545, entitled Optical Identity System and Methods, filed Jan. 29, 2016, which is incorporated herein by reference in its entirety. An embodiment may use P(TM(openssl)) to provide identification, authentication, and authorization operations enabled by the OpenSSL toolkit (see www.openssl.org website).

[0151] Example of Thing type An action block is a thing:graph representing a sequence of statements. A named action block is called a task. In this way, a language grammar can express requests to a thing machine that constitute named tasks that the thing machine can execute in sequence. Tasks are executed by executing action blocks. Action blocks are executed by evaluating each statement to produce an executable thing:graph. The executable thing:graph is executed by executing the actions that correspond to the thing:verbs in the executable thing:graph.

[0152] The Singing Machine may be configured to be bilingual in the sense that multiple language grammar parsers may be configured as executable operations. Alternatively, a translation operation may be used to translate from a first language to a second language that can be parsed by the configured parser operation.

[0153] Thus, when we say that a thing machine can read a book, we mean that the thing machine can perform operations that interact with content obtained from an input device and represent the content as a thing:graph. By maintaining the thing:graph as a subgraph of the overall thing machine, thing machine operations can continue to access and interact with that content.

[0154] The thing machine reads a book that describes how to perform a task and retains that knowledge if the machine is called upon to perform such a task in the future. Tasks can be categorized by topic. A task might be a member of a set of categories of tasks related to the use of the http protocol, activities such as accounting:account.receivable, accounting:accounts.payable, banking:debits, banking:credits, and banking:balance.

[0155] A first thinging machine can send a communication to a second thinging machine requesting knowledge about a topic or classification. In response to receiving content representing said knowledge, the first thinging machine can interact with the content and configure its own knowledge accordingly. In this manner, the first thinging machine can learn from the second thinging machine.

[0156] A thing machine can provide services. A service is a thing that is provided in response to receiving a request. The fine distinction between services and tasks is that tasks are executed while services are provided. The separation of tasks and services is promoted through contexts, which can prevent unauthorized execution of tasks such as a task that removes a file or a task that changes the meaning of a verb.

[0157] As stated, a context thing identifies a set of namespace things available in the conversation domain. A namespace thing identifies a set of related things, even if they are related only by being members of the same namespace. The name of the namespace thing is used in resolving references to the thing.

[0158] Identity is a thing, and therefore the concepts of identifiers, authentication, authorization, and auditing can be modeled to implement the identity model. Examples of identity models include the use of public key infrastructure, Open PGP's Web of Trust, biometrics, third party authentication, etc. Identity can be used to introduce marketplaces as things and enable transactions. Transactions become things between buyers and sellers, payers and paid. Transactions can involve service provision things, physical things, conceptual things, or logical things.

[0159] The identity model allows for the authentication of graphs or subgraphs. For example, consider a graph representing a request that includes an identifier of the requesting party (i.e., the request originator), the content, and a digital signature of the content. The corresponding certificate of the identifier can be verified, and the digital signature of the content can be verified. This allows an evaluation operation to algorithmically validate the request and select an appropriate action in response. The identity model can also be implemented to provide a secure communication model.

[0160] Securing the request content can be modeled using encryption operations that encrypt the content and subsequently decrypt the content. The request graph can include subgraphs that describe the encryption operations and encryption keys. To decrypt the content, an evaluation verb operation can be applied that must first perform a specified encryption with a specified key as a prerequisite. By organizing the various components of the request in the appropriate subgraphs, two or more thing machines can algorithmically communicate and secure the communication using the identity model.

[0161] When integrated with an optical identifier SIM card or similar device, the Thing Machine can be modeled as a Thing that has a unique identity in the overlay network, even on an ad-hoc basis: the Thing can drop out of the network and re-enter elsewhere in the network and still retain its optical identity.

[0162] The optical identity can be separate from the user identity, allowing the Thing Machine to validate itself in the overlay network and reconfigure itself based on the user's identity using content available in the network.

[0163] The Thing Machine can dynamically compose and reconfigure the vocabulary, even on an ad-hoc basis. A set of Thing Machines that share an ontological commitment with at least a subset of the vocabulary can interact with the Thing using that subset (or at least a part of the subset). Because the vocabulary is represented as a Thing and the Thing Machine has verb actions to compose and reconfigure the vocabulary, the Thing Machine can learn, examples of which are provided herein.

[0164] With reference to the exemplary RDF thing described herein for illustrative purposes, the following exemplary definitions apply:

[0165] Graph - a collection of points and lines connecting some (possibly empty) subset of the points. The points of a graph are most commonly known as graph vertices, but are sometimes called "nodes" or simply "points". Similarly, the lines connecting the vertices of a graph are most commonly known as graph edges, but are sometimes called "arcs" or "lines".

[0166] A graph node is called graph:node. A graph edge is called graph:edge. An edge can have a label called graph:edge-label.

[0167] Directed Graph - A directed graph is a graph, i.e., a set of objects (called vertices or nodes) connected together, in which all edges (directed graph edges) are directed from one vertex to another. Directed graphs are sometimes called digraphs or directed networks.

[0168] A directed graph is called graph:directed.

[0169] A directed graph edge is called graph:directed-edge.

[0170] Undirected Graph - An undirected graph is a graph in which all edges (undirected graph edges) are bidirectional, i.e. a set of objects (called vertices or nodes) connected together. Undirected graphs are sometimes called undirected networks. An undirected graph is called graph:undirected. An undirected graph edge is called graph:undirected-edge.

[0171] Subgraph - A subgraph is a graph whose vertices and edges are a subset of another graph.

[0172] Root Graph - A root graph is a directed graph in which one node is designated as the start (root) node.

[0173] In accordance with the present system and method, ABNF is used to describe the representation of the immutable components of a thing governed by P(TM(thing)), and RDF is used to further express the semantics of the immutable and mutable components of the thing governed by P(TM(thing)).

[0174] -ABNF In the example diagrams provided herein, we use an augmented backus-naur form (ABNF) specification to describe a thing governed by P(TM(thing)), as shown below. In particular, we describe a thing governed by P(TM(thing)) and its non-mutable components below. scheme:scheme-name = ALPHA*(ALPHA / DIGIT / “+” / “-” / “.”) scheme:scheme-specific-part = This is scheme specific. For details about scheme-specific parts, see the RFC corresponding to the scheme name. If no such RFC exists, the scheme-specific part is parsed into a thing identifier defined by the thing language. Otherwise, the scheme-specific part is tokenized according to the scheme.

[0175] The following ABNF rules apply: thing:identifier = 1*1(scheme:scheme-name / scheme:scheme-specific-part) thing:char-literal = char-val thing:num-literal = num-val thing:bin-literal = bin-val thing:dec-literal = dec-val thing:hex-literal = hex-val thing:value = 1*(thing:char / thing:num / thing:bin / thing:dec / thing:hex)

[0176] The class id identifies the class of the thing. The default class id is a URI, and the thing identified by the URI is a classification. The default is thing:thing. thing:class.id=URI

[0177] thing:set(i) is a set of things for which i is. A general set is thing:set.of(thing:thing), a set of things. A set has no things with duplicate names. thing:set.of(i)=0,*(i) thing:list(i) is a list of things that are members of class i. A general tuple is thing:list.of(thing:thing), a list of things. A list may have duplicate (i). thing:list.of(i)=0,*(i) Note: In one embodiment, parameters can be referenced as thing:value.of(i), thing:name.of(i), thing:thing(thing:name.of((thing:value.of(i))), etc.

[0178] -Single RDF The Resource Description Framework (RDF) is a framework for representing information on the Web. An RDF triple has three components: a) a subject, which is an IRI or a blank node, b) a predicate, which is an IRI, and an object, which is an IRI, a character, or a blank node. RDF triples are conventionally written in the order subject, predicate, object. An RDF graph is a set of RDF triples.

[0179] RDF triples are used in the following sections describing things and in thing graphs, where predicates indicate relationship types between subjects and objects. The thing:is-a relationship type indicates that the subject is a member of the class of things identified by the object. The thing:has-a relationship type indicates that the subject has a non-mutable component given by the object. Note that the values ​​of the components can change, but the components cannot. See relationship types for more information.

[0180] The reference P(TM(i)) is a reference to an algorithmic procedure of the sub-i machine, where i is an identifier that identifies a first procedure of the sub-i machine from a second procedure of the sub-i machine.

[0181] A thing is a node in the graph supervised by P(TM(thing)). thing:thing thing:is-a graph:node

[0182] A thing has a name, a value, a class, and a set of relationships. In a preferred embodiment that provides backward compatibility for the World Wide Web, the namespace thing name is sheme:name. P(TM(thing)) can set, get, or unset a thing.

number

[0183] The following rules state that a relationship set consists of zero or more relationships. A relationship set with zero relationships is the empty set. A root thing:graph of thing:thing with a relationship set that is the empty set is the empty graph of thing:thing (thing:graph:empty). thing:relationship-set = thing:set.of(thing:relationship(x,r,o))

[0184] In the following rules, s, r, and o are parameters that indicate: there exists a relationship-type (r) between thing:subject(s) and thing:object(o). P(TM(thing)) can set, get, or unset the relationship. thing:relationship(s,r,o) = thing:subject(s)thing:relationship-type(r)thing:object(o)

[0185] The following rule should be interpreted as: There is a thing whose name is equal to s. thing:thing(s) = thing:thing, where is-equal.to = (thing:name.of(thing:thing),(s))

[0186] The following rule should be interpreted as: There is a thing whose name is equal to s and whose value is equal to v. thing:thing(s,v) = thing:thing, where (is:equal.to = (thing:name.of(thing:thing),(s)) and is:equal.to = (thing:value.of(thing:thing),(v)))

[0187] In one embodiment, components of a Thing can be referenced. For example, the following rule is interpreted as the Thing [where [name=a] and [value=b]]: thing:thing(0,1[name = a]0,1[value = b]) = thing:thing However, is:equal.to = (thing:value.of(thing:name),(s)) and is:equal.to = (thing:value.of(thing:value),(v))

number

[0188] Hereinafter, a rule (s,c,o) is parameterized to say that the claim given by c is satisfied by (s) and an optional thing:object(o). As a thing, the rule is interpreted as saying that there is a subject thing (s) such that there is a satisfying claim c such that there is an optional object (o). thing:assert(s,c,o) = *(thing:subject(s) thing:predicate(c) thing:object(o))

[0189] The following rule is equivalent to the value of the name component of the thing given by parameter (i). thing:name.of(i) = thing:value.of((i):name)

[0190] The following rule is equivalent to the value of the value component of Thing given by parameter (i). thing:value.of(i) = thing:value.of((i):value)

[0191] Below are example relationship types: thing:is-a The subject thing is a member of the class denoted by the object. thing:has-a The subject thing has a non-variable component identified by the object. thing:sttia There is a subject thing such that there is an object thing. thing:sttiai There is a subject thing such that there are instances of the object thing. thing:sttmb There is a subject thing such that there can be an object thing. thing:sttina There is a subject thing without an object thing. thing:parent The object thing is the parent of the subject thing. thing:child The object thing is the child of the subject thing. thing:next The object thing is the next sibling of the subject thing. thing:prior The object thing is the earlier sibling of the subject thing.

[0192] The thing:is and thing:is.not assertions are thing:predicate satisfaction claims. A satisfaction claim is thing:expression = thing:subject thing:satisfaction-claim 0,1(thing:object) The form of the expression may be given by:

[0193] Satisfaction claims are asserted by thing:verbs that operate on claims. This allows the set of accessible satisfaction claims to be self-constituting for a particular embodiment. A subset of satisfaction claims includes: thing:is.lt The value of the subject thing is less than the value of the object thing. thing:is.lteq The value of the subject thing is less than or equal to the value of the object thing. thing:is.eq The value of the subject thing is equal to the value of the object thing. thing:is.gteq The value of the subject thing is greater than or equal to the value of the object thing. thing:is.gt The value of the subject thing is greater than the value of the object thing. thing:is.not.empty The value of the subject thing is not empty. A thing:graph(s) is a graph of thing:subject(s). A thing:graph(monad) is a supergraph of related things.

number

[0194] thing:class(class.id) is a thing:thing given by thing:name class.id. It has a relationship to a discipline that exists within the context of that class.

number

[0195] Example thing:classes include: a) thing:class(thing:char), b) thing:class(thing:num), c) thing:class(thing:bin), d) thing:class(thing:dec), e)thing:class(thing:hex) There is.

[0196] Exemplary disciplines include: a)thing:discipline(c,thing:set) b)thing:discipline(c,thing:get) c)thing:discipline(c,thing:unset) There is.

[0197] An embodiment may add a set of modifiers that modify P(TM(discipline(c,d))). Exemplary modifiers include: a)thing:before(thing:discipline(c,d),thing:urr(u)) b) thing:as(thing:discipline(c,d),thing:urr(u)) c)thing:after(thing:discipline(c,d),thing:urr(u)) thing:before urr is evaluated before thing:discipline(c,v), and if it is satisfied, thing:discipline(c,v) is evaluated next. thing:as urr is evaluated as if it were G(urr(d)). The thing:after urr is evaluated after the successful evaluation of G.urr(d) or, if specified, thing:as urr.

[0198] New taxonomies are constructed by constructing a class thing:class(class.id) graph with appropriate relationships to the disciplines.

[0199] A thing:verb is a thing:thing supervised by P(TM(thing)) such that there is a representation of a reference to an executable action that can be resolved into an executable action that P(TM(perform)) can cause to be performed. P(TM(perform)) is said to perform the thing:verb by causing the executable action to be performed.

number

[0200] thing:urr(i) is a uniform resource request that requests the execution of P(TM(i)). The P(TM(i)) operation binds the value of thing:urr(i) to an executable operation that P(TM(perform)) can perform. In an exemplary embodiment, this may include binding to an address of an instruction in non-transitory memory, and embodiments may further feature the use of one or more operating system calls such as fork, exec, pthread#create, connect, open, send, write, receive, read, close, wait, and / or disconnect.

[0201] In evaluating a request to execute P(TM(i)), P(TM(eval)) interacts with P(TM(thing)) to determine P(TM(i)) and algorithmically prepare a graph of P(TM) things that are required to be accessible to P(TM(i)). In one embodiment, the graph is generated in the context of the request namespace that is specifically generated for the duration of the P(TM(i)) operation, and the response, if there is one, is set in the context of the response namespace. This allows P(TM(eval)) to push a new context onto the context stack of P(TM(i)) and algorithmically interact with the response namespace to update the things overseen by P(TM(thing)) accordingly.

[0202] A thing:verb.vocabulary is a thing:thing that has a relationship to a set of thing:verbs.

number

[0203] The corresponding executable actions of thing:urr(i) are executed by P(TM(i)) to constitute a verb thing in the verb vocabulary.

[0204] Example thing:relationship Further illustrated below is one embodiment of a thing relationship: As shown by the directed graph in Figure 19, a thing named x is a predecessor of a thing named y, and y is a successor of a thing named x, and the predicate is a thing such that there is a relationship denoted as thing:sttia. The English interpretation is there is a thing with name equal to x, which has a thing with name equal to y. The "such that there is a" relationship is denoted with a thing:sttia edge label.

[0205] As shown by the directed graph in Figure 20, a thing named x is a predecessor of a thing named z, and the predicate is "such that there is an instance", which is shown as thing:sttiai. The English interpretation is: there is a thing with name equal to x, and there is an instance of a thing with name equal to z.

[0206] As shown by the directed graph in Figure 21, the English interpretation is given as: there is a thing with name equal to x which has a thing with name equal to y which has a thing with name equal to z which has a reference to a thing with name equal to x. Such that three is a reference to relationships are shown at the thing:sttiart edge level. The references can be in the form of a URI which can be interpreted as a list.

[0207] A thing named x is a thing:table, as shown by the directed graph in Figure 22. The graph can be traversed in either direction using the next edge and last edge pairs and the parent-child edge pairs.

[0208] As shown by the directed graph in FIG. 23, many things have relationships to one thing.

[0209] As shown by the directed graph in FIG. 24, a Thing named x is a member of the class of Things named "c".

[0210] A predicate can express a relationship over the non-mutable components of a Thing. As shown by the directed graph in Figure 25, the relationship indicates that the name of a Thing named "x" is a member of the class of Things named "b".

[0211] As illustrated by the directed graph in FIG. 26, the relationship indicates that a value of a Thing named x is a member of a class of Things named "c".

[0212] The following is an example thing supervised by P(TM(thing)) in supervision of things in the graph:

[0213] thing:monad - A monad is the first thing that can identify all other things supervised by P(TM(thing)). The nodes of the directed graph are things, and the directed edge labels are the propositions that hold between the connected things. The monadic directed graph shows the state of the thing machine. Monads are connected with an edge directed to the context thing with the directed edge label "such that, there is a", denoted as "thing:sttia".

[0214] thing:context - A context thing represents a set of things organized as a stack, where the top of the stack is the thing that represents the current context. New context things can be algorithmically pushed onto the stack, or algorithmically pushed off the stack, changing the current context. An instance of a context thing is the root of a directed graph of the set of things that are the namespaces within that context.

[0215] thing:namespace - A namespace is a thing that represents a named graph of things that are logically related in some way, even if they are related merely by being members of the same namespace. The name of the graph conforms to the naming requirements of the International Resource Identifier (IRI) scheme. The namespace root directed graph starts with the namespace thing as the root, and the connected nodes are things qualified by the namespace thing. The directed edge labels indicate the relationships that hold between the connected things.

[0216] A context thing qualifies a set of available namespaces thing. Exemplary namespaces include request, response, local, service, core, and boot namespaces. Additional namespaces can be configured through the operation of P(TM(thing)). The following graph applies to each namespace of a context, and non-named nodes in the graph are bound to namespaces qualified by the context. As shown by the directed graph in Figure 27, a context includes the request, response, and local namespaces. An embodiment can self-configure the set of namespaces.

[0217] Exemplary namespaces are provided below in Table 3.

[0218] [Table 3]

[0219] Mapping IRIs to Namespaces IRI scheme names are mapped to namespace names, and then the scheme-specific parts of the IRI are mapped according to the rules of the particular namespace. The default behavior is to use the dot (".") character delimiter to indicate "such that there is a" relations, and bracket delimiters ("[" and "]") to indicate "such that there is an instance of" relations. For example, reference:request:statement[1].word is There is a namespace thing with name equal to "request", which has a thing with name equal to "statement", which has an instance of a thing with name equal to "1", which has a thing with name equal to "word" is interpreted as:

[0220] As noted in the SingGraph Data Model section, all permanent URI schemes are reserved namespace names, as published by the Internet Assigned Numbers Authority. A complete list of reserved namespaces is published online at http: / / www.iotnamespaces.com / reserved. A mapping of IRIs to reserved namespaces is also available at www.iotnamespace.com / mappings.

[0221] Identifying things using XML Basic XML is parsed and bound in namespaces. This is important for services that use the Basic XML format, such as the Weather Service, identified by the URL http: / / w1.weather.gov / xml.current#obs / inex.xml. To show the mapping,

number

[0222] [Table 4]

[0223] In basic XML mapping, elements are mapped to things and attributes are mapped as instances of attributes of that thing.

[0224] XML Schema Definition From our previous example using weather station XML data, the local:station.xml#url element has a value that identifies a resource that represents the local data for the station. To retrieve that resource, we do, in part:

number

[0225] When parsing XML, the default behavior is to interpret elements as things and attributes as instances of attributes on that thing. The following triplets shown in Table 5 are true:

[0226] [Table 5]

[0227] As a formal assertion, the triplet There is a thing with name equal to "current#observation" and there, name is equal to "xmlns:xsd", and There is an instance of Thing whose value is equal to "http: / / www.w3.org / 2001 / XMLSchema", and name is equal to "xmlns:xsi", and The value is equal to "http: / / www.w3.org / 2001 / XMLSchema-instance" There is an instance of Thing and name is equal to "xsi:noNamespaceSchemaLocation" and The value is equal to "http: / / www.weather.gov / view / current#observation.xsd" There is an instance of Thing It can be expressed as:

[0228] An XSD reference allows an XSD schema to be searched so that the valid structure of the object's elements, subelements, and attributes can be represented in a namespace as a thing.

[0229] XML Namespaces In XML, a qualified name is a name that is subject to namespace interpretation. Both elements and attributes are qualified names. When parsing an XML document according to the XML Namespaces specification, the document is parsed into the required namespaces and validated, using qualified names as thing names to preserve the document's structure. For example, consider the XML document given below. The book element contains two namespace attributes: the first namespace attribute defines the default XML namespace, and the second namespace attribute defines the isbn XML namespace. The XML 1.1 specification does not require the IRI to be a validated IRI, rather it requires that the IRI be specified as a syntactically correct IRI. Therefore, the parsing operation does not map XML IRI references into thing namespaces.

number

[0230] [Table 6]

[0231] The formal satisfaction claim is as follows: There is a namespace thing with name equal to "request" that contains There is a thing whose name is equal to "book"; name is equal to "xmlns" and There is an instance whose value is equal to "urn:loc.gov:books", and name is equal to "xmlns:isbn", and There is an instance whose value is equal to "urn:ISBN:0-395-36341-6".

[0232] Sing Language In the thing graph model, all things are things. Some things are namespaces, some are verbs, and some are things on which verb actions can act. The relationship between verbs and the set of things they can act on is represented as a thing-verb graph.

[0233] The classification allows one to infer the meaning of the intended action. However, in the following example statements, where the intended action is to "set" something using a time and a unit of time, the action required for each statement is quite different: Set the timer to 6:00 minutes Set the clock to 6:00AM Set your alarm for 6:00 PM

[0234] A parse operation is executed to parse the statement as a thing:graph thing graph. An evaluate operation evaluates the thing:graph in the context of the verb vocabulary graph to select candidate verbs. An evaluateverb operation binds things in the request graph to things in the candidate verb graph to identify instances of the verb graph that need to be executed. An execute operation is triggered to execute the identified verb action in the context of the bound thing.

[0235] Singing Statement The Sing language provides both imperative and declarative statement structures. In general, the minimal boot vocabulary is suitable for imperative use, while the more expressive core vocabulary allows for declarative use. An ABNF definition of the Sing statements is provided below. The ABNF syntax is defined in RFC2234.

number

[0236] As an example, the following statement instructs the thing machine to set the thing identified by the list request:my.name to the value John: set=(request:uri="request:my.name" request:value="John")

[0237] Using the P(TM(bind)) action, the above statement set=(request:my.name="John") A list can be bound to a thing that an action can act on, so that you can specify

[0238] In general, the same syntax applies to any statement in the thing language, where the thing on which the verb action can act is contained within the delimiters "(" and ")".

number

[0239] This simple syntax of the Sing language is easily translated into other languages. For example, the above statement can be expressed in JSON as follows:

number

[0240] Similarly, example statements can be expressed using THING / XML.

number

[0241] Any number of languages ​​and syntaxes can be used, as long as the parser is able to parse the data into a thing:graph.

[0242] Multipart data is supported, as shown below. This example presents a simple statement based on the verb set. Note that request:listing is not specified. The evaluate verb action interacts with the request:graph and the corresponding verb graph in the verb vocabulary to bind things in the request:graph to things that the verb can interact with. In this example, the value of request:listing defaults to rcd:Contact and the value of request:class defaults to thing:thing.

number

[0243] The above statement is equivalent to:

number

[0244] Declarative statements follow the same general syntax as imperative statements. To illustrate the difference, we'll start with a simple example that uses three imperative statements to initialize the list painting:Gallery as an auto-instanced thing. A thing classified as thing:auto-instance causes a new instance to be added automatically each time the thing is used in a set verb action.

number

[0245] Then, use the following statements to express what you want without needing to detail each step:

number

[0246] Namespace Scope A namespace is a thing that represents a named graph of things that are logically related in some way, even if they are related merely by being members of the same namespace. A namespace thing is qualified by a context thing, and the name of the graph (the name of the namespace) conforms to the naming requirements of the IRI scheme. All permanent URI schemes are reserved namespace names as published by the Internet Assigned Numbers Authority.

[0247] classification Things can be classified as being members of classes of Things. All Things are Things. Some Things are integers, some are floats, some are sets, etc. The namespace system is self-organized with a set of core classes, within which additional classes can exist. Chapter 2 provides more information about classes.

[0248] The following example performs a set action and is interpreted as: there is a thing with name equal to local, and this thing is a namespace such that there is a thing with name equal to scores. ·set=(listing="local:scores") The following example describes a request to set the score as a floating point number. ·set=(class=float listing="local:scores" value="83.25")

[0249] Communication Primitives A communication primitive is something that provides an interface for communication. Primitives allow common actions such as connect, send, receive, and disconnect. Communication primitives are provided for various types of communication, including web things, sockets, files, RS232, URI schemes, and uniform resource request lists.

[0250] Communication points A communication point is a thing with which communication primitives interact to make communication occur. Usually a local file

number

number

number

[0251] statement In the Sing language, a statement contains a verb and zero or more object name=expression pairs. Each expression is either a value expression or a name=expression pair. Binders can bind verb-modifier phrases separated by dots.

number

[0252] Name expressions are qualified by names that contain name expressions. Thus, a=(b=1) is interpreted as there is a thing with name equal to a, which has a thing with name equal to b and value equal to 1. A multi-part statement such as a=(b=1 c=2) is interpreted as there is a thing with name equal to a, which has a thing with name equal to b and value equal to 1, and there is a thing with name equal to c and value equal to 2.

[0253] Value expressions are characters and may be quoted. Character values ​​that contain space characters must be quoted. Thus, a=house, a="house", and a='house' are equivalent. Similarly, a="red house" and a='red house' are equivalent.

[0254] Mathematical expressions are enclosed in double parentheses and do not need to be enclosed in quotes. For example, a=((10+-2 * (6 / 3))). The normal order of operations applies, and expressions may be enclosed in parentheses. Functions are not supported, only mathematical verbs. Thus, a=((2 * sqrt(4))) will be evaluated as expected as long as sqrt is a verb in the mathematical verb vocabulary.

[0255] To express the statement explicitly, the format is

number

[0256] Operational Block An action block is a sequence of statements that should be evaluated as a unit. This allows the namespace system to execute blocks, allowing logic to deal with true and false type statements. The general syntax for an action block is:

number

[0257] In the following example, a simple action block sequence is:

number

[0258] conditions The namespace system provides for conditional evaluation of actions: IF, ELSE-IF, and ELSE conditions are supported.

number

[0259] Iteration Repetition is made possible by the for and while conditional verb actions.

number

[0260] setting The set verb action sets the thing matched by the value of request:listing according to the rules of the classification identified as request:class. If a class is not explicitly specified, the evaluate verb action determines the appropriate classification based on the things in the statement.

[0261] In the following statement, the classification defaults to request:class="thing:thing" and the corresponding verb graph is shown in Figure 28.

number

[0262] In the following statement, the classification defaults to request:class="thing:alarm" and the corresponding verb graph is shown in Figure 29.

number

[0263] The verb statements of the configuration are shown here: As new classifications are added, additional verb actions may be needed to support the meaning of the classification, and these may be added to the vocabulary using verb modifiers.

number

[0264] thing:graph - a thing:graph is a directed graph of things and their associated things, which may be represented as a subgraph of all possible things and their relationships from a root directed graph. A non-named verb level is interpreted as a thing:identifier. In other cases, one or more named non-variable components and expressions may be used as the apex level. In the preferred embodiment, Name:name and Value:value are used to denote thing:identifier and thing:value, respectively, when such a distinction is required. An unnamed vertex in the thing:graph is the set of things in the conversation domain that are qualified by the predecessors of the unnamed vertices, if any, that fill the unnamed vertex directed graph. thing:subgraph-P(TM(i)) can operate on a thing:subgraph of the monadic root directed graph. thing:statement - a thing:graph representing the statement to evaluate. thing:statement.declarative - Declarative thing:statement. thing:statement.imperative-imperative thing:statement. thing:statement.interrogative-interrogative thing:statement. thing:statement.exclamatory-exclamatory thing:statement. thing:listing - A list is a representation of a reference to a thing. A qualified list contains a representation of a reference to a namespace and has the general format "namespace:namespace-specific-part", and is equivalent to a URI consisting of "scheme:scheme-specific part". An unqualified list (also called an unbound list) can be algorithmically qualified by P(TM(bind)). A thing:list is resolved by the algorithmic operation of P(TM(thing)).

[0265] Name-specific parts can be resolved through the use of the get, set, and unset disciplines of a given namespace, allowing predicate algorithm operations to resolve references even when the interpretation of the namespace-specific part depends on the namespace being modeled.

[0266] Free variables Representations of references to things are considered free variables. P(TM(bind)) algorithmically binds references in a set of things defined by the context. When traversing the thing:graph, the context of a thing is algorithmically updated to reflect the things that are applicable within the thing's current scope in the conversational universe. Consider the following assertion: There is a thing, there is a thing with name equal to Contact, and there is a thing with name equal to Email.

[0267] The opening reference "there is a thing, and there is" indicates that all possible things in the conversation domain overseen by P(TM(thing)) are considered to be in the current set of things. P(TM(thing)) then disqualifies all things in the current set for which the restriction "there is a thing whose name equals Contact, and there is a thing whose name equals Email" does not hold.

[0268] Referring to Figure 30, G.request(P(TM(i))) indicates that P(TM(i)) can operate on things qualified in the request namespace. An unnamed node indicates that P(TM(i)) can operate on some thing qualified in the request namespace without identifying the thing by name.

[0269] Referring to FIG. 31, G.request(P(TM(i))) indicates that P(TM(i)) can act on a thing named contact that is qualified by a thing named statement that is qualified in the request namespace.

[0270] Referring to FIG. 32, an example G(P(TM(i)) is a rooted directed thing:graph that contains a G.request(P(TM(i))) subgraph, which indicates how P(TM(perform)) should request P(TM(i)) to perform an operation. Note that the components of request:statement.Thing satisfy the components of the thing schema defined by http: / / www.schema.org / Thing.

[0271] Uniform Resource Request A Uniform Resource Request (URR) thing is a URI that can be interpreted by P(TM(thing)) as a request for an actionable action to be performed. For example,

number

[0272] What distinguishes a URR from a conventional URI is that a URR is evaluated in the context of a thing in the thing:namespace, instead of a request that a server provide the identified resource.

[0273] The stdlib:load thing is an active thing that dynamically loads the library that an executable action corresponds to, resolves references to the value of the entry thing as an executable action, and executes the action. The action is typically implemented using the dlopen() and dlsym() calls or the equivalent calls on Windows, Linux, BSD, iOS, or other such operating systems. See http: / / pubs.opengroup.org / onlinepubs / 009695399 / functions / dlopen.html.

[0274] The response from the execution of an action is a set of thing:statements that ask the thing machine to construct a thing:verb that injects into the loaded action. P(TM(bind)) can be used to bind an entry point reference to an executable action using dlsym() or an equivalent operating system call.

[0275] The stdlib:unload thing is an active thing whose executable action is to unload the corresponding library. The action is usually performed using dlclose. See http: / / pubs.opengroup.org / onlinepubs / 009695399 / functions / dlclose.html.

[0276] Care must be taken to keep in mind the distinction between client and server resource resolution when using URRs and URIs: URRs are resolved to resources by the thing machine, whereas URIs are generally resolved to resources by the server.

[0277] P(TM(i)) can generate a URR and request P(TM) to evaluate and execute the appropriate action. As an example, P(TM(parse)) can interact with content, parse the content, and discover that it is in a format or language that the parser action does not understand. In such a case, P(TM(parse)) can request the evaluation and execution of a second P(TM(i)) action that may be able to parse the content.

[0278] A first thing machine with communications capabilities can communicate a request to identify a thing (or the content of a thing) to a second thing machine. The second thing machine can teach the first thing machine what something represents, the actions that can be performed on it, and / or the tasks that can be performed using it.

[0279] Core POSIX Vocabulary Core POSIX.1-2008 defines a standard operating system interface and environment, including command interpreters (or "shells") and common utility programs that support application portability at the source code level. It is intended for use by both application developers and system implementers. See http: / / pubs.opengroup.org / onlinepubs / 9699919799 / .

[0280] The core vocabulary follows the POSIX.1-2008 system API, but not all application programming interfaces are currently provided. The parameters are things, and where appropriate, conversion between strings and actual integers is provided by the corresponding verb actions. An embodiment of the thing may include a non-mutable component of system specific data, thereby providing a pointer to a data structure where necessary. As an example, the POSIX standard defining the unlink() function is defined as "int unlink (const char*path", which is implemented as a verb action named "unlink" that operates on a thing identified by the list request:path. In an embodiment, the function is implemented as a verb thing (i.e., thing:verbs) and configured in the verb namespace, although a suitable namespace such as POSIX may be used instead, and the context for resolving references is set appropriately. Application domain specific algorithmic procedures may be configured. For example, a commonly used verb action such as http:get may be configured to retrieve a resource specified by a URI using the GET method of the HTTP protocol.

[0281] Executables can be composed as verb actions using inter-process communication or standard file descriptors. For example, the / bin / date(1) command is well known in the Unix and Linux community and can be composed, but the output may need to be parsed into a suitable format to implement the parsing. For example, the list bin:date may have an executable action that exec(2)s the / bin / date executable in a separate address space and pipes the output as the value of the response. The URR bin:date / / response:as=”data:date” is interpreted as a request to execute the bin:date verb action and the response (read from the command's standard output) composed as the value of the thing given by the list date:date.

[0282] Using a well-defined set of verb actions, task sequences can be translated into source code that can be compiled and run as an executable, eliminating the steps of evaluating statements and binding things.

[0283] thing:machine A thing describing one embodiment of a thing machine is a thing:machine. Referring to Figure 66, P(TM) parses content expressed in a thing language that describes the configuration desired for P(TM). P(TM) interacts with P(TM(thing)) to construct a thing:graph that represents P(TM), where the thing:graph is a thing:machine thing.

[0284] Those skilled in the art of public key infrastructure can implement authentication operations to ensure the authenticity of content, such as through the use of X509 certificates, digital signatures, and OpenSSL identity, authentication, and authorization algorithm operations.

[0285] Referring to Figure 66, the thing:graph describing the thing:machine is: a) boot vocabulary, b) Core vocabulary, and c) Application Runtime Vocabulary and d) Hardware and e) Operating System Synchronization It consists of a set of things that indicate vocabulary, including optional things from a set containing

[0286] Note that the hardware thing may include a processor thing that describes the processor and one or more component things. The hardware thing may include a vocabulary thing.

[0287] A set of things that describe a vocabulary is a) a uniform resource request requesting the loading of a verb vocabulary executable; b) content describing the thing:graph of thing:verbs, c) a list of vocabulary; d) Mandatory Conditions Sing; e) Discipline Sing, f) Thing, which identifies the author; g) A vendor identification number that may be separate from the owner; h) A sign identifying the owner, which may be distinct from the creator; i) the signature used to authenticate the content; j) The signature used to authorize use of the content; and k) Properties from http: / / www.schema.org.SoftwareApplication It can be composed of:

[0288] Note that the application vocabulary URR is evaluated using stdfile:parse, which performs the operation of reading and parsing the file as thing:statements. In an embodiment, the statements include a set of tasks to configure, a runtime task, and a set of services to provide. In an embodiment, the tasks and the services that comprise the action blocks and tasks are executed by executing the action blocks of the tasks. Similarly, the services are provided by executing the action blocks of the services. One skilled in the art can configure numerous tasks and services.

[0289] Below is an example of content expressed in the Singe language, which describes TM(i):

[0290] TM: Raspberry Pi 3 Below is an example of content expressed in the Singe language, which describes TM(i):

number

[0291] TM(RaspberryPi3) is a computational machine configured to run P(TM) which includes the following operations: running a self-configured thing:machine.boot.vocabulary executable to interact with thing:machine.hardware.component.parts, configuring thing:machine.application.vocabulary, and configuring thing:machine.core.vocabulary to run an application runtime.

[0292] TM(AMS.TMD26723) The following is an example of content expressed in the Sing language, which describes a TM(i): The TMD26723 is a digital proximity detector, LED driver, and IR LED in optical module 1.8v 12C interface (see http: / / www.ams.com) provided by AMS Corporation. The product datasheet is available at http: / / ams.com / eng / content / download / 364923 / 1210537 / 207915.

number

[0293] TM(AMS.TMD26723) is a calculator configured to interact with the TM2671 using i2c communications configured as specified by the datasheet and providing the P(TM(AMS.TMD26723))) operations listed in Table 7 below.

[0294] [Table 7]

[0295] Note that in the preferred embodiment, P(TM(i)) algorithmically interacts with P(TM(thing)) to access and interact with things that the P(TM(i)) operation can act on. P(TM(i)) interacts with P(TM(thing)) to set the status to FAILED and the reason to INVALID VALUE for any value that is not within the range of values ​​allowed by the P(TM(i)) operation. In the preferred embodiment, the reference names of the operations are constructed in the TMD26723 namespace, although the second embodiment may use a different namespace.

[0296] Additional operations can be included in an embodiment, including an operation that opens a communication channel to the TMD26723 using an i2c interface, thereby enabling operations to act on the thing that represents the channel, which is useful when multiple TMD26723 sensors are used in an embodiment.

[0297] TM(piborg.ultraborg) Ultraborg is a precision servo control with ultrasonic module support, interface board with i2c communication. The board provides 4HC-SR04 ultrasonic distance sensor connectors and up to 4 servo motor connectors. The HC-SR04 has a 30 degree field of view.

[0298] Below is an example of content expressed in the Singe language, which describes TM(i):

number

[0299] TM(piborg.ultraborg) is a calculator configured to interact with an Ultraborg using i2c communications configured as specified by the datasheet to provide the P(TM(piborg.ultraborg)) operations shown in Table 8.

[0300] [Table 8]

[0301] Note that in a preferred embodiment, P(TM(i)) interacts algorithmically with P(TM(thing)) to access and interact with things that the P(TM(i)) operation can act on. P(TM(i)) interacts with P(TM(thing)) to set the status to FAILED and the reason to INVALID VALUE for any value that is not within the range of values ​​allowed by the P(TM(i)) operation.

[0302] In the preferred embodiment, the action reference names are constructed in a specified namespace, although a second embodiment may use a different list.

[0303] In one embodiment, the HC-SR04 ultrasonic sensor is mounted to a surface that can be rotated by the motion of a servo motor. In this way, the servo motor can rotate the surface in increments of 30 degrees, etc., allowing the ultrasonic sensor to cover incrementally larger areas.

[0304] In a second embodiment, the HC-SR04 ultrasonic sensor is mounted in a fixed position, such as facing forward, to measure distances up to 4m with a fixed 30 degree field of view.

[0305] TM(Ublox.neo-6m-gps) The Neo-6M-GPS is a ublox 6 GPS module ROM crystal that uses the standard GPIO interface.

[0306] Below is an example of content expressed in the Singe language, which describes TM(i):

number

[0307] TM(Ublox.neo-6m) is a calculator configured to interact with a u-blox Neo 6M GPS using generic i / o configured as specified by the datasheet, and providing the P(TM(Ublox.neo-6m)) operations shown in Table 9.

[0308] [Table 9]

[0309] Note that in the preferred embodiment, P(TM(i)) algorithmically interacts with P(TM(thing)) to access and interact with things that the P(TM(i)) operation can act on. P(TM(i)) interacts with P(TM(thing)) to set the status to FAILED and the reason to INVALID VALUE for any value that is not within the range of values ​​allowed by the P(TM(i)) operation. In the preferred embodiment, the reference names of the operations are constructed in a specified namespace, although the second embodiment may use a different list.

[0310] TM(HC-SR501) HC-SR501 Pyroelectric Infrared PIR Motion Sensor Detector Module The following is an example of content expressed in the Sing language, which describes TM(i):

number

[0311] The TM(HC-SR501) is a calculator configured to interact with the PIR using a generic I / O interface specified by the datasheet, providing the P(TM(HC-SR501)) operations shown in Table 10.

[0312] [Table 10]

[0313] Note that in the preferred embodiment, P(TM(i)) algorithmically interacts with P(TM(thing)) to access and interact with things that the P(TM(i)) operation can act on. P(TM(i)) interacts with P(TM(thing)) to set the status to FAILED and the reason to INVALID VALUE for any value that is not within the range of values ​​allowed by the P(TM(i)) operation. In the preferred embodiment, the reference names of the operations are constructed in a specified namespace, although the second embodiment may use a different list.

[0314] Cirrus Logic Audio Card The Cirrus Logic Audio Card is manufactured by Element14 in collaboration with Cirrus Logic and offers Raspberry Pi® users the flexibility to capture audio in parallel with a camera, similar to a PC sound card, and to experiment with stereo digital capture and playback.

[0315] Below is an example of content expressed in the Singe language, which describes TM(i):

number

[0316] TM(Element14.CLAC) is a calculator configured to interact with a Cirrus Logic audio card interface as specified by the datasheet, a stereo microphone connected to the stereo line inputs, and two externally powered stereo speakers connected to the stereo line outputs, and providing the P(TM(Element14.CLAC)) behavior shown in Table 11.

[0317] [Table 11]

[0318] Note that in the preferred embodiment, P(TM(i)) algorithmically interacts with P(TM(thing)) to access and interact with things that the P(TM(i)) operation can act on. P(TM(i)) interacts with P(TM(thing)) to set the status to FAILED and the reason to INVALID VALUE for any value that is not within the range of values ​​allowed by the P(TM(i)) operation. In the preferred embodiment, the reference names of the operations are constructed in a specified namespace, although the second embodiment may use a different list.

[0319] An exemplary embodiment for a Cirrus Logic Audio Card TM (Element14.CLAC) is shown below. https: / / www.element14.com / community / servlet / JiveServlet / downloadBody / 65689-102-2-291406 / Wolfson%20Audio%20Card%20Schematic%20Diagram.pdf

[0320] TM (TI.TMP007) The TMP007 is an integrated digital thermopile temperature sensor in a wafer chip scale package (WCSP) that detects the temperature of distant objects by infrared (IR) radiation. See http: / / www.ti.com / lit / ds / symlink / tmp007.pdf.

[0321] Below is an example of content expressed in the Singe language, which describes TM(i):

number

[0322] TM(TI.TMP007) is a calculator configured to interact with a TI TMP007 as specified by the TMP007 datasheet and provide the P(TM(TI.TMP007)) behavior shown in Table 12.

[0323] [Table 12]

[0324] Example of P(TM(i)) As mentioned above, the Singing Machine is composed of multiple TM(i), where each TM(i) is a computer that uses a procedure P(TM(i)). Examples of various P(TM(i)) include, but are not limited to, the following:

[0325] The P(TM(format)) operation interacts with P(TM(thing)) to format the response namespace thing as an outbound content response that the P(TM(output)) operation outputs. Note that the algorithmic steps of P(TM(format)) and P(TM(output)) can be combined into a single procedure given by the appropriate P(TM(i)), such as P(TM(format.output)).

[0326] A P(TM(runtime)) operation interacts with P(TM(thing)) to execute a composed task thing:graph, which represents a sequence of statements, each of which is evaluated by P(TM(eval)), and the corresponding executable thing:graph is executed by P(TM(perform)).

[0327] P(TM(runtime)) is algorithmically 1. Interact with P(TM(thing)) to set the value of the thing given by its list status to the value "satisfied", 2. While the value of the above is equal to "satisfied", execute the following sequence repeatedly: interacts with aP(TM(parse)) to read content from an input device, parses said content, and interacts with P(TM(request)) to generate a corresponding thing:statement graph; interacts with bP(TM(eval)) to evaluate the graph in the context of the active thing, producing an executable thing:statement graph; Interact with cP(TM(perform)) to execute the executable thing:statement graph above. Provides an action.

[0328] P(TM(runtime)) can be configured as an active thing in a set of boot active things. A P(TM(bootstrap)) operation can initialize a communication channel and set up a thing that represents that communication channel. A P(TM(parse)) operation can access and interact with that thing as a communication channel to interact with P(TM(thing)) to retrieve content.

[0329] P(TM(runtime)) can be configured as an active thing in a set of bootstrap active things. A P(TM(bootstrap)) operation can initialize a communication channel, set up a thing that represents that communication channel, and then request the execution of P(TM(runtime)). A P(TM(parse)) operation can access and interact with that thing as a communication channel to interact with P(TM(thing)) to retrieve content.

[0330] For unknown things, P(TM) can interact with P(TM(bind)), which provides an operation that interacts with P(TM(thing)) to bind the unknown thing as a member of a class of things that P(TM) knows.

[0331] P(TM(classifier)) algorithmically classifies the type of statement it is being asked to evaluate as a classification of interest and increments a count of that classification of interest. At a given threshold, P(TM) adds that classification as a topic to a list of things P(TM) should learn. P(TM) can algorithmically determine an appropriate time to learn about a topic. Using a communication device, P(TM) can request content related to the topic. This allows P(TM) to determine the type of topic it wants to learn about and the rate at which it wants to learn. For example, a thing machine running at 75% memory capacity, 65% processing capacity, and / or 60% network capacity may postpone spending additional resources on learning until a later time. In many cases, a thing machine will typically focus on an area of ​​interest related to the environment in which it is running. However, by adding random selections to the list of topics to learn from, the thing machine can expand its capabilities to be more general. For example, a thing machine that is a vending machine that vends products can learn the actions required to provide car rentals. On the surface it may seem silly, but consider a vending machine in a busy airport where many car rental agencies are readily available. Such a machine can learn to use web services to discover which car rental companies have a suitable selection for the consumer, book the rental, charge the consumer, and email the consumer a receipt. P(TM(classifier)) can provide the operation of classifying the thing:statement, and P(TM(eval)) uses the classification to identify a set of active things that satisfy the thing:statement and are available to P(TM(eval)) in selecting an active thing. Other forms of artificial intelligence (AI) can also be integrated. For example, symbolic AI, sub-symbolic AI, and statistical AL algorithmic procedures can be used.

[0332] P(TM(eval)) can generate and execute a first executable thing:statement and use the response to execute a second executable thing:statement. In one embodiment, the first executable thing:statement can execute P(TM(classifier)) to classify the type of thing:statement being evaluated, such as a topic. In response, P(TM(eval)) can use the classification to generate a second executable thing:statement or to set an accessible active thing context for the generated executable thing:statement.

[0333] Referring to FIG. 33, P(TM(parse)) interacts with an input device (not shown) and P(TM(thing)) to provide operations to generate a request thing:graph, P(TM(eval)) interacts with P(TM(thing)) to provide operations to evaluate the request thing:graph in the context of accessible executable operations to generate an executable thing:graph, and P(TM(perform)) interacts with P(TM(thing)) to provide operations to execute the executable thing:graph, where said graph is executed by P(TM(configure)) to modify the graph of executable operations that P(TM) can perform. In one embodiment, the input device is a file system device and the content is a configuration document that syntactically conforms to a language grammar that describes at least one active thing to configure. In a preferred embodiment, the parsing and formatting operations conform to the thing language grammar. In this configuration, the vocabulary of active things is dynamically configured from a set of configuration documents.

[0334] Referring to Figure 34, P(TM(env)) interacts with an input device (not shown) and P(TM(thing)) to provide operations to generate a request thing:graph, P(TM(eval)) interacts with P(TM(thing)) to provide operations to evaluate the request thing:graph in the context of executable operations to generate an executable thing:graph, and P(TM(perfrom)) interacts with P(TM(thing)) to provide operations to execute the executable thing:graph, where P(TM(configure)) modifies the graph of executable operations that P(TM) can perform.

[0335] In a preferred embodiment, the input device is an electromagnetic wave device. In this configuration, parts of the thing:graph (monad) are algorithmically altered based on input from the environment, so that P(TM) adapts to the needs of the environment in which it is running.

[0336] In one environment, a P(TM) operation plays an audio message asking the user "How can I be of service" and a second operation records the user response. A speech-to-text operation converts the audio to text, which is parsed as a thing:graph. A classifier operation algorithmically classifies the topic of the conversation. P(TM) communicates a request for a task related to the topic to a second thing machine. In response to receiving the information, the first P(TM) algorithmically composes a task and executes the task.

[0337] In a second embodiment, the thing machine includes a receiving optical subsystem assembly and is used to query a user-provided Optical Identifier (OI) and, in response, configures a portion of the thing:graph(monad) to contain an executable thing:graph specific to that user. When the user performs a positive action, such as by removing the OI from the optical reader, P(TM) forgets that portion of the user-specific thing:gram(monad).

[0338] In a third embodiment, the thing machine includes a biometric device, such as an EyeLock, that identifies the user and performs an action that configures a portion of the thing:graph(monad) to include an executable thing:graph specific to that user. When the user performs a positive action, such as by leaving the area of ​​the biometric device, P(TM) forgets that portion of the thing:gram(monad) specific to the user.

[0339] P(TM(thing)) provides operations to algorithmically initialize and organize in non-volatile memory as a thing:graph a representation of things and relationships between things. In one embodiment that supports classes, P(TM(thing)) is composed of discipline P(TM(thing:class)) procedures such as P(TM(thing:class.set)) which sets a thing that satisfies the requirements of what is intended for an instance of a thing to be a member of that class, P(TM(thing:class.get)) which gets a reference to a thing of that class, and P(TM(thing:class.unset)) which unsets an instance of a thing of a specified class. Modifier operations such as "before" or "after" can qualify P(TM(thing)) procedures, thus allowing "before setting, perform this operation" or "after setting, perform this operation".

[0340] Each instance of a thing is composed of a set of non-mutable components used by P(TM(thing)). In a preferred embodiment, the set includes thing:name, thing:value, and thing:relationship-set. An embodiment can extend the set to incorporate additional components specified through content that P(TM(thing)) can interact with, such as content in a configuration file.

[0341] Referring to Figure 35, during initialization, P(TM(thing)) assigns and initializes the thing with name equal to monad as the root of the thing machine's thing:graph, assigns and initializes the thing with the name context, and sets up a relationship such that the assertion "there is a thing with name equal to monad, and in that thing there is a thing with name equal to context" is true.

[0342] 36, a context identifies a set of things that are within the scope of resolving a list consisting of one or more free variables and expressions of relationships between the free variables. For example, http: / / www.iotnamespace.com / thing, request:statement, and statement.thing[1] are examples of lists.

[0343] 37, in a preferred embodiment, a context thing is a thing:stack through which P(TM(thing)) can algorithmically push things onto the stack or push things off the stack, thereby changing the context. P(TM(thing)) algorithmically uses the thing at the top of the stack as the current context when identifying a set of things that are within scope to resolve the list.

[0344] Referring again to Figure 36, in a preferred embodiment the current context thing has a relationship set that includes relationships to one or more things called namespace things. The name of a thing is the name of a namespace. P(TM(thing)) algorithmically uses the namespace thing as a thing to represent a named thing graph of related things, even if they are only related by being qualified in the same namespace. The URI scheme name can be the name of a thing, which is a namespace. The URI scheme specific part is a list identifying things that are qualified in that namespace.

[0345] With reference to Figure 38, a thing that has a representation of a reference to an executable operation is classified as an active thing. An active thing is a thing:verb with a corresponding active thing graph G(P(TM(i))). Subject node names are replaced by the corresponding active thing name, and G.requests that operate on blank nodes are replaced by the graph of things that P(TM(i)) can act on. Each G(P(TM(i))) is a) A thing, G.identifier(P(TM(i)) whose name is an identifier that identifies P(TM(i)) and is the root node (subject thing) in the directed graph; b) a G.urr(P(TM(i))) URI whose value indicates a request to P(TM(i)) to act on G.request; and c) A sing graph G.request(P(TM(i))) showing the set of sings on which P(TM(i)) can act. Includes.

[0346] Referring to FIG. 39, in one embodiment, G(P(TM(i))) may include additional thing information, such as a description of the thing including the response from the execution of P(TM(i)).

[0347] An embodiment may include multiple G.request graphs for a given G(P(TM(i))), which indicate various permutations of things that P(TM(i)) can act on. Such an embodiment may further include multiple G.response graphs, which indicate the things that make up the corresponding response graph.

[0348] Figure 40 is the G(P(TM(Thing.set))) graph corresponding to the P(TM(Thing.set)) procedure for setting things in non-transient memory. The value of the request:uri thing is a list of things to set, and its value, if specified, is set to the value of the request:value thing. If the request:using thing is specified, its value is a list representing the things to use in setting the thing identified by the value of the request:uri thing.

[0349] Figure 41 is the G(P(TM(thing.get))) graph corresponding to the P(TM(Thing.get) procedure which obtains a representation of the Thing given by the list request:uri, non-transient memory. The qualifiers name, value, relationship set, or relationship can be used to indicate the specific information requested about the Thing. The information is stored as the value of the Thing given by the list indicated by the value of request:as Thing.

[0350] Figure 42 is the G(P(TM(Thing.unset))) graph corresponding to the P(TM(Thing.unset) procedure which unsets a representation of a thing from non-transient memory. The thing to unset is given by the value of the request:uri thing.

[0351] One skilled in the art can replace P(TM(thing)) with alternative algorithmic procedures that supervise things and relationships to allow for further features such as concurrency, persistence, caching, synchronization, locking (such as read / write locks), ownership, permissions (such as read / write / execute by owner, group, or all), etc.

[0352] P(TM(eval)) P(TM(eval)) algorithmically interacts with P(TM(thing)) as illustrated in Figure 45 to a) Select the thing:statement to evaluate, b) selecting G(P(TM(i))) as a viable active thing from the set of accessible active things; c) initializing the new context thing as an executable context thing; d) execute G.urr of the executable G(P(TM(i))) in the context of the executable context Sing; e) resetting the executable context thing to the current context thing; f) Unset the new context thing Provides an action.

[0353] In one embodiment, steps a and b consist of selecting an active thing that satisfies the asserts: (there is a thing:statement whose list equals request:statement and there is a thing whose name equals .name) and (there is a thing:verb whose list equals verb.vocabulary and there is a thing whose name equals .name and the thing is the active thing).

[0354] In a preferred embodiment, step b may include the step of selecting a default active thing if the assertion is not satisfied.

[0355] For an active thing with instances, P(TM(eval)) may include selecting an instance of the active thing whose thing:statement is a subgraph of the instance's G.request graph.

[0356] In one embodiment, P(TM(eval)) interacts with P(TM(bind)) to bind the thing identified by the thing:statement thing using the corresponding G.request graph of the executable operation thing as a thing in the executable context thing on which the active thing operation can act.

[0357] In one embodiment, P(TM(eval)) algorithmically classifies the type of statement as imperative, declarative, interrogative, or exclamatory, and executes active methods to evaluate the classes of statements, such that a P(TM(eval.declarative)) procedure can algorithmically evaluate declarative statements, a P(TM(eval.imperative)) procedure can algorithmically evaluate imperative statements, a P(TM(eval.interrogative)) procedure can algorithmically evaluate interrogative statements, and a P(TM(eval.exclamatory)) procedure can algorithmically evaluate exclamatory statements.

[0358] The P(TM(eval)) operation can algorithmically select a default active thing for an executable thing:statement, and can algorithmically evaluate the thing:statement to determine an appropriate active thing for use. The default operation can interact with P(TM(thing)) to increment a counter associated with the classification of the thing:statement for which the default operation was performed to represent the number of times the thing machine has been asked to perform that classification of the thing:statement. Using executable communication operations, P(TM(i)) can communicate with a second machine to obtain content associated with said classification. The P(TM(parse)) operation can parse the thing:statement for evaluation and execution. In this way, the thing machine can adapt to the needs of the environment in which it is running. (The goal here is to ask the machine to do something. The machine chooses a default action, and then evaluates whatever it was asked to do and see if there is a better action to perform. If there isn't, the machine performs the default. The default action classifies a topic and increments a counter of the number of times the machine has been asked to do something related to that topic. This way, once the counter reaches a threshold, the machine can ask someone to teach it about the topic, or buy and read a book related to the topic.)

[0359] One embodiment can merge graphs between contexts such that if the response.as thing is specified, P(TM(eval)) can bind a subgraph of the response:namespace thing in the new context as a subgraph of the response.as thing in the current context before unsetting the new context thing.

[0360] In one embodiment, P(TM(eval)) may include pushing the new context onto the context stack as the current context prior to executing G.urr. In a second embodiment, one skilled in the computer art of parallel processing may use a thing to represent a graph of thread-specific data for a process control block thing, said data including a reference to the current context, to resolve P(TM(thing)).

[0361] Referring to Figure 43, G.request indicates that an operation can act on a request:statement, which is a thing:statement. Thus, a subgraph of the request:statement thing must meet the requirements for being a member of the class of things that are thing:statements.

[0362] Referring to Figure 44, the G.request subgraph shows that an action can act on a request:using thing that is a thing:listing. This graph applies if it is true that there is a request namespace thing, there is no thing whose name equals statement (thing:sttina), and there is a thing whose name equals using. This G.request subgraph provides an alternative way of selecting the evaluation active thing.

[0363] Algorithmic uses of artificial intelligence are explicitly contemplated. P(TM(classifier)) provides the operation of classifying a thing:statement, and P(TM(eval)) uses the classification to identify a set of Active Things available to P(TM(eval)) in selecting an Active Thing that satisfies the thing:statement. Other forms of artificial intelligence can also be integrated. For example, symbolic AI, sub-symbolic AI, and statistical AI algorithmic procedures can be used.

[0364] Google Research has released TensorFlow, an open source machine learning library used primarily for academic and research activities. Those skilled in the computer science field of machine learning can use the TensorFlow API to develop a P(TM(classifier)) for deep learning. The TensorFlow API can be modified to directly interact with P(TM(thing)) as a set of active things that represent the constituent Tensorflow procedures. Training data can be provided through the set of active things.

[0365] P(TM(eval)) provides operations that a) interact with P(TM(thing)) to generate a request classifier thing:statement to request the execution of P(TM(classifier)) to classify the current request thing:statement, b) interact with P(TM(bind)) to bind the classifier thing:statement as an executable thing:statement, c) interact with P(TM(perform)) to execute the executable thing:statement, and d) interact with P(TM(thing)) to interact with its result.

[0366] The result identifies the classification (class) relevant to the current thing:statement. For a class of thing known to P(TM), P(TM(eval)) interacts with P(TM(thing)) to set up a context to include the vocabulary relevant to the class, and evaluates the current thing:statement in that context.

[0367] P(TM(eval)) increments a counter representing a topic that indicates the number of times that topic applies to the current request thing:statement, allowing the classifier to classify thing:statements according to their most frequently used topics. If P(TM) does not have vocabulary for a given topic, P(TM(eval)) can generate and evaluate a thing:statement that represents a default behavior.

[0368] A first P(TM) can communicate with a second P(TM), such as through Wi-Fi communication, to request content related to a class of thing:statement that P(TM) is generally required to evaluate and execute. Such content may represent things, such as active things, and things on which the actions of active things can act, such as tasks.

[0369] An embodiment may replace P(TM(eval)) with an evaluation operation that algorithmically performs an evaluation appropriate to an embodiment, such as an embodiment that supports a given language, implements a particular machine learning algorithm, performs multiple machine learning algorithms, provides performance improvements, or interacts with a second machine to evaluate a thing:statement and interacts with a third machine to execute the thing:statement. Those skilled in the art will appreciate that many algorithmic variations are possible within the scope of the present invention.

[0370] Modifiers can be used as things in thing:statement to modify the default P(TM(eval)) procedural action. Alternatively, P(TM(eval)) can interact with P(TM(classifier)) to algorithmically classify the type of thing being evaluated, and the type of thing can be used as a modifier to select the active thing to execute. As an example, evaluating a statement that represents an imperative statement such as "Perform the task named cleanup" is different from evaluating a statement that represents a declarative statement such as "The declaration of a task named cleanup includes step 1: flush compoint I / O and step 2: close compoint I / O."

[0371] By incorporating into the thing:graph of P(TM(i)) the types of things that an action can act on, and the types of things that the action can respond to, it is possible to select an appropriate action for a common verb name such as open. As an example, each of the following have very different actions, but each use a common verb name: open an email, open a gate, open a bank account. The choice of exact action depends, in part, on what is being opened. By including a description of the types of things that the action can act on, P(TM(eval)) can make appropriate choices about the executable thing:graph to generate.

[0372] P(TM(parse)) P(TM(parse)) provides operations that parse input representing a request and interact algorithmically with P(TM(request)) to set up a thing that represents the parsed input. In a preferred embodiment, P(TM(parse)) is an XML 1.1 parser.

[0373] Referring to Figure 46, the value of the thing identified by the list request:stream is the stream to parse. The thing identified by the value of the request:as thing, which defaults to request:statement, is set as the thing:statement representing the parsed input request.

[0374] Referring to Figure 47, the example XML fragment is parsed into an example graph, where element attributes are represented via "such that there is an instance" relationships (thing:sttiai), while elements are represented via "such that there is a" relationships (thing:sttia).

[0375] Referring to Figure 48, the value of the thing given by the request:input list is the input to parse. TM(eval) selects the appropriate G.request(P(TM(parse))) graph based on the request graph and facilitates the appropriate binding.

[0376] Note that there are subtle but important differences between Parse 1 and Parse 3, particularly in 1 where the operation reads from a stream. Instead, in 3 the operation uses the value of the request:input list (the value is the content to parse).

[0377] This is necessary because in certain cases the content is obtained from a file, and in other cases the operation generates the content and stores it as the value of the thing.

[0378] P(TM(request)) P(TM(request)) provides operations that interact algorithmically with P(TM(Thing)) to set up, as a thing:statement thing graph, the thing identified by the list given as the value of the request:as thing, using the thing identified by the list given as the value of the request:using thing.

[0379] We can iteratively build the thing:statement thing using first P(TM(i)), and then algorithmically interact with P(TM(request)) to populate the request:statement thing. Figure 49 shows the G(P(TM(request))) graph. The default value of the request:as thing is request:statement.

[0380] P(TM(bind)) P(TM(bind)) algorithmically applies a set of bind rules in an attempt to bind a thing as a member of a given class of things.

[0381] As an example, a thing whose value matches the pattern "[0-9]{1,}" may be bound as thing:integer, while a thing whose value matches the pattern "[0-9A-Fa-f]" may be bound as thing:hexadecimal. In addition to base classes of things such as thing:thing, thing:text, thing:integer, thing:float, and thing:string, additional types can be expressed using inference rules or schemas.

[0382] Referring to Figure 50, the G.request subgraph indicates the things that P(TM(bind)) can act on. The value of a thing given by request:using is a list that identifies a set of bind rules. The value of a thing given by request:bind.listing is a list that identifies the thing:graph to bind to. The value of a thing given by reqeust:response.as is a list that identifies the thing:graph to set the response to. If request:response.as is empty, the graph of the thing being bound is updated.

[0383] P(TM(bind)) can use state information such as unbound or bound to indicate whether a thing is already bound or not. This allows P(TM(bind)) to check the state and execute bind rules only on unbound things. P(TM(bind)) can also include "discovered" and "undiscovered" states to indicate whether a thing is bound and discovered, or bound and undiscovered. In a preferred embodiment, P(TM(unbind)) interacts with P(TM(thing)) to reset the thing to the unbound-undiscovered state.

[0384] In a first embodiment, one skilled in the art of computer science logic uses inference rules to bind a thing as a member of a class of things. A rule consists of an assertion and a class identifier. P(TM(bind)) interacts with P(TM(thing)) to algorithmically apply the rule as an assertion about the thing to be bound, and if satisfied, P(TM(bind)) interacts with P(TM(thing)) to identify the thing as a member of said class identifier.

[0385] In a second embodiment, one skilled in the art of computer science markup languages ​​can use the thing:schema markup language to describe a thing class. Industry standard markup schemas are available at http: / / schema.org.docs / schemas.html. The schema is a set of types, each with a set of associated attributes. See http: / / schema.org / docs / documents.html for Schema.org schema information, which is incorporated by reference.

[0386] Referring to Figure 51, thing:graph is interpreted as an assertion describing the membership requirements of things that are bound as members of the image object class. The interpretation is an assertion expressing that there is a thing whose name equals schema, where there is a thing whose name equals ImageObject and thing is thing:schema, where (there is a thing whose name equals Caption and thing:value is thing:text) and (there is a thing whose name equals exitData and thing:Value is thing:text) and (there is a thing whose name equals representativeOfPage and thing:value is thing:Boolean) and (there is a thing whose name equals thumbnail and thing:thing is schema:ImageObject).

[0387] Referring to Figure 52, we present an unbound thing:graph given by the list local:object.

[0388] Referring to Figure 53, the thing:graph indicates a request to bind the local:object thing:graph as a schema:ImageObject thing (as described in http: / / www.schema.org / ImageObject). P(TM(bind)) interacts with P(TM(Thing)) to determine whether the components of the local:object thing:graph meet the requirements to be a schema:ImageObject. The local:object thing state transitions from unbound to bound. If so, a node "bound.found" is added to the local:object thing:graph and the value of the node is set to schema:ImageObject.

[0389] One skilled in the art of computer science logic can use inference rules to algorithmically make inferences about a thing. An inference rule consists of a procedure that operates on a thing:graph representing the premises to produce a thing:graph representing the conclusion. Referring to Figure 54, an assertion describes what it means for a thing to be classified as a BroadcastService. The assertion is parsed and expressed as an inference rule for the specified classification. P(TM(bind)) provides an operation that algorithmically evaluates whether a specified thing:graph satisfies the inference rule, and if so, classifies the thing:graph as a member of the specified classification. Referring again to Figure 54, one skilled in the art of computer science schema can generate number-theoretic rules for a set of schemas, such as the set published by http: / / www.schema.org, available at http: / / schema.org / docs.full.html.

[0390] Note that http: / / www.schema.org / PerformAction relates to actions that participate in the performance of art, not machines that perform executable actions. Note further that schema.org actions relate to the vocabulary that allows websites to describe the actions they enable and how clients can invoke those actions. See http: / / blog.schema.org / 2014 / 04 / announcing-schemaorg-actions.html, which is incorporated by reference.

[0391] P(TM(perform)) P(TM(perfrom)) algorithmically executes an executable thing:statement by finding a reference to P(TM(i)) in the thing:statement and causing the P(TM(i)) action to be executed. The response from the action is either satisfied, unsatisfied, or failed. The P(TM(perform)) action sets a status thing value to indicate this response.

[0392] Referring to FIG. 55, the G.request subgraph shows that the P(TM(perform)) operation acts on the request:statement.

[0393] P(TM(task)) P(TM(task)) algorithmically interacts with P(TM(thing)) to supervise the thing:graph as a thing:task consisting of a set of subgraphs containing thing:lists of thing:statements. In one embodiment, the operation of P(TM(task)) is: a) P(TM(task.set)) interacts with P(TM(thing)) to set thing:task; b) P(TM(task.get)), which interacts with P(TM(thing)) to obtain a reference to thing:task, c) P(TM(task.unset)) interacts with P(TM(thing)) to unset thing:task; d) P(TM(task.perform)) evaluates and executes the thing:statement in the thing:task by interacting with P(TM(thing)), P(TM(eval)), and P(TM(perform)). It can be composed of:

[0394] Referring to Figure 56, P(TM(task.set)) interacts with P(TM(thing)) to algorithmically act on things identified by the list request:statement.task, which is a list of things whose values ​​should be set as thing:task. The action subgraph of request:statement.task is set as a subgraph of the thing:task thing. One embodiment may include the G.request subgraph as request:statement.task.G.request, which represents the things on which the task should act.

[0395] P(TM(task.get)) interacts with P(TM(thing)) to algorithmically obtain a representation of the thing:task, primarily for use by other P(TM(i)) that need to access that graph, such as P(TM(task.perform)).

[0396] P(TM(task.unset)) interacts with P(TM(thing)) to algorithmically unset (remove) the specified task from the thing:thing(monad) graph.

[0397] Referring to Figure 57, P(TM(task.perform)) interacts with P(TM(thing)), P(TM(eval)), and P(TM(perform)) to algorithmically evaluate and execute the sequence of thing:statement subgraphs given by the action subgraph of thing:task identified by the value of request:statement.task.

[0398] In one embodiment, a thing:task graph can contain thing:statement subgraphs that can be evaluated and executed as prerequisites to evaluate and execute a thing:task action subgraph. This allows a set of action things to be executed to obtain a content representation representing the action subgraph, and parse that content as a thing:statement sequence of the action subgraph to be evaluated and executed. Other operations can include identification, authentication, and authorization to verify, authorize, or deny execution of a thing:task. Similarly, prerequisite operations can be used to ensure that prerequisites are met before evaluation of a thing:task, such as configuring an active thing.

[0399] In one embodiment, a thing:task may contain an on.status subgraph representing thing:statements to evaluate and execute depending on the value of the status thing. After each thing:statement is evaluated and executed, one embodiment may interact with a P(TM(thing)) operation to algorithmically test the status to see if the value is satisfied, unsatisfied, or failed, and evaluate and execute the corresponding on.status.satisfied, on.status.unsatisfied, or on.status.failed thing:statement subgraph.

[0400] An embodiment may include an on.status subgraph that represents thing:statements to evaluate and execute depending on the value of the status thing. After each thing:statement is evaluated and executed, an embodiment may interact with a P(TM(thing)) operation to algorithmically test the status to see if the value is satisfied, unsatisfied, or failed, and evaluate and execute the corresponding on.status.satisfied, on.status.unsatisfied, or on.status.failed thing:statement subgraph.

[0401] P(TM(format)) P(TM(format)) provides operations that interact with P(TM(thing)) to traverse the thing:graph and generate a formatted representation of the thing:graph. By way of example, the representation of the thing:graph can be formatted as an XML document, an HTML document, a thing document, or any other such format as required by an embodiment.

[0402] Referring to Figure 58, request:statement.listing identifies a thing whose value is a list representing the thing:graph that P(TM(format)) should format. request:statement.as identifies a thing whose value is a representation of the thing:graph representing the generated formatted response. request:statement.using identifies a thing whose value is a representation of the desired format.

[0403] The default P(TM(format)) to use is Thing-XML. Nodes of the thing:graph that are traversed are formatted as root elements. Subgraphs that are instances are formatted as attributes, while non-instance subgraphs are formatted as inner elements.

[0404] In one embodiment, P(TM(format)) can interact with P(TM(thing)) to traverse the thing:graph to generate a text stream and P(TM(text-to-speech)) to perform synthesis of the text stream into an audible stream containing a synthetic speech text representation. P(TM(play-audio)) communicates the audible stream to the sound subsystem to generate the audible playback.

[0405] P(TM(http:get)) P(TM(http:get)) provides operations that algorithmically interact with P(TM(thing)) to generate URIs, communicate HTTP GET method requests for resources identified by the URIs, receive HTTP responses, and generate a thing:graph representing the HTTP response including a response.headers thing:subgraph and a response.entity thing:subgraph.

[0406] One skilled in the art of computer science web services can provide HTTP methods such as connect, delete, get, head, options, post, put, and trace in a vocabulary using a set of HTTP method active things. The set of methods can be configured for the http:namespace. Similarly, one skilled in the art can provide a set of methods related to the HTTPS protocol, and the set can be configured as an active thing for the https:namespace.

[0407] Referring to Figure 59, the URI thing qualifies the request thing which qualifies the domain thing, the path thing, and the header thing. P(TM(http:get)) interacts with P(TM(thing)) to algorithmically interact with the URI thing to generate an HTTP Get method request (shown in Figure 60) and communicate said request to the domain web service. In response, P(TM(http:get)) receives a response (see Figure 61).

[0408] Referring to FIG. 61, P(TM(http:get)) receives the response from the HTTP Get method request, parses the response, and performs operations to interact with P(TM(thing)) to set up a thing:graph representing the response, such as that shown in FIG. 62.

[0409] A set of request header field components, each represented as a component qualified by request:header, can be constructed in the request.header thing. Similarly, in response to receiving and parsing a response header, a set of response header field components, each represented as a component, can be constructed in the response.header thing.

[0410] In one embodiment, P(TM(http:get)) performs an operation to interact with P(TM(thing)) to obtain a set of things representing acceptable media types in the response, and adds an allowed request header field to the request header thing:subgraph accordingly. In a second embodiment, P(TM(http:get)) performs an operation to interact with P(TM(thing)) to obtain a set of acceptable encodings in the response, and adds an allowed encodings header field to the request header accordingly.

[0411] P(TM(parse.html)) P(TM(parse.html)) interacts with P(TM(thing)) to algorithmically provide the operations required to parse a thing:graph representing HTML content into a set of thing:graphs.

[0412] Referring to Figure 63, P(TM(parse.html)) operates on the request.content thing, whose value is a list representing things, whose value is the HTML content to parse. Anchor links embedded in HTML that are found within the same domain as the HTML content are classified as internal links and are added to the thing:graph of the thing identified by the request:links.internal thing value. Similarly, external links are added to the thing:graph of the thing identified by the request.links.external thing value. Untagged text is stored in the value of the thing identified by the request:text thing value. HTML tags are added to the thing:graph of the thing identified by the request:architecture thing value. Microdata is added to the thing:graph identified by the request:microdata thing value.

[0413] Referring to Figure 64, we show example microdata in HTML content. P(TM(parse.html)) interacts with P(TM(thing)) to parse the content and provide operations to represent the microdata as a thing:graph, as shown in Figure 65.

[0414] As shown, the first schema may include a second schema, such as an organization, and may include an address as described by http: / / www.schema.org.

[0415] TM(openssl) Portions of P(TM(openssl)) are covered under the OpenSSL license agreement, which is included in this disclosure. TM(openssl) is the OpenSSL open source software and computer program implemented with P(TM(OpenSSL)). OpenSSL is well known in the state of the art and provides TLS and SSL protocol operations, a general-purpose cryptographic library, and is widely used with Web services to support public key infrastructure programs. See http: / / www.openssl.org for more information.

[0416] In learning the P(TM(openssl)) thing:verbs, P(TM) can perform a set of operations typically provided by a certification authority. For example, one skilled in the art of computer science public key infrastructure can use the P(TM(openssl)) thing:verbs to encrypt content, decrypt content, generate hash codes, generate certificate signing requests, sign certificates, create self-signed certificates, verify certificate requests, verify certificates, revoke certificates, algorithmically examine components of a certificate, generate digital signatures, verify digital signatures, provide a set of services typically associated with a certification authority, authorize the use of a certificate for a purpose, and enable the use of the SSL / TLS protocol.

[0417] When used with P(TM), the OpenSSL source code was modified so that the original C source code functions interacted with P(TM(thing)) and referenced the thing as a parameter. One skilled in the art of computer science could modify a similar existing source code library to compose additional P(TM(i)) using a composition operation.

[0418] In general, OpenSSL commands are constructed as operations that P(TM) can perform where the command name is constructed as a thing:verb, and the parameters that the command acts on are constructed as things that the thing:verb operation can act on.

[0419] Some of the P(TM(i)) may operate on content that represents data, which may be further categorized as a certificate signing request, a certificate, a password, a private key, a public key, configuration information, a certificate to revoke, an extension, random data, or some other type of thing that the operation can act on. In some cases, the content is parsed by P(TM(i)) and represented as a thing in a thing graph, while in other cases the content is used as the value of a thing given by a list. In many cases, the thing that an operation can act on can be specified as a Thing.urr, which is interpreted as a uniform resource request for that thing. Similarly, P(TM(i)) may algorithmically generate content that represents data, which may be further categorized as described above.

[0420] In some cases the content may be analyzed by P(TM(i)) and represented as a thing in a thing:graph, while in other cases the content may be used as the value of a thing given by a list. An operation may interact with a system device driver to retrieve or store the content in a second storage device, communicate the content to a second P(TM), or communicate the content to a sensor or device.

[0421] In general, for a thing that can have a value, the thing may be specified as thing:name.urr=URR in a thing:statement being evaluated by P(TM(evaluate)) to generate an executable thing:graph, where URR is a uniform resource request. For clarity, we call this step 1.

[0422] In traversing the thing:statement thing:graph, P(TM(evaluate)) looks at thing:name.urr, evaluates the URR, and produces an executable thing:graph. The executable thing:graph is executed to produce a response thing:graph. P(TM(evaluate)) in step 1 uses the response thing:graph when evaluating and binding the thing:statement thing.

[0423] Specific examples of P(TM(openssl)) operations are provided on the following pages to provide sufficient explanation for the reader, and then the rest of the openssl commands that follow the same format.

[0424] Some of the P(TM(i)) operations can operate on a common set of things, which are provided in Table 13 below.

[0425] [Table 13]

[0426] P(TM(openssl.ca)) P(TM(openssl.ca)) provides the minimal certificate authority operations. The things that the openssl.ca verb operations can act on are listed in Table 14 below.

[0427] [Table 14]

[0428] [Table 15]

[0429] P(TM(openssl.x509)) P(TM(openssl.x509)) provides operations to provide certificate information, convert certificates to various forms, sign certificate requests (similar to a mini Certificate Authority), or edit certificate trust settings.

[0430] It can be used to display certificate information, convert certificates to various forms, sign certificate requests as a "mini-CA", or edit certificate trust settings. The things that the openssl.x509 verb actions can act on are listed in Table 15.

[0431] [Table 16]

[0432] [Table 17]

[0433] [Table 18]

[0434] [Table 19]

[0435] [Table 20]

[0436] [Table 21]

[0437] [Table 22]

[0438] P(TM(openssl.genrsa)) P(TM(openssl.genrsa)) provides an operation to generate an RSA private key. The things that the P(TM(openssl.genrsa)) operation can operate on are included in Table 16.

[0439] [Table 23]

[0440] P(TM(openssl.req)) P(TM(openssl.req)) provides the operations for requesting certificates and generating certificates. The things that the P(TM(openssl.req)) operation can act on are listed in Table 17.

[0441] [Table 24]

[0442] [Table 25]

[0443] [Table 26]

[0444] P(TM(OI)) The TM(OI) interacts with the optical reader device driver to a. Set the read angle P(TM(OI:set.angle)), b. Set the position (P(TM(OI:set.position)), c. Optically interrogating the optical identifier (P(TM(OI:interrogate)); d. Generate a corresponding bitmap of the digital data P(TM(OI:generate)); Interact with eP(TM(thing)) to generate a thing:graph that represents the codepage The computer has a procedure P(TM(OI)) configured to provide operations including:

[0445] Similarly, the algorithmic operations of the '545 IOT-Modules can be implemented as a set of P(TM(i)) that are configured for use within P(TM). Thus, the teachings of '545 can be implemented as a set of things that represent operations and things on which the operations can act.

[0446] Exemplary P(TM) Exemplary P(TM) include startup, main, and shutdown as follows: 1. P(TM(startup)), 2. P(TM(main)), and 3. P(TM(shutdown)).

[0447] In one embodiment, P(TM) is stored in a non-transitory secondary storage device of the thing machine. In a second embodiment, P(TM) is encoded in a code page of an optical identifier as shown in U.S. patent application Ser. No. 62 / 288,545, entitled "Optical Identifier System and Methods," filed Jan. 29, 2016, which is incorporated herein by reference in its entirety. A thing machine having an optical subassembly can optically query the optical identifier to provide a representation of the program instructions to an executable memory.

[0448] A first procedure of the TM, such as a bootstrap procedure, loads P(TM) into executable processor memory, such as from a code page, a non-transitory secondary storage device, or received using an electromagnetic device, and causes the processor to perform operations that cause the processor to execute P(TM).

[0449] P(TM(startup)) is 1. Run P(TM(thing)) and initialize P(TM) thing:subject(monad) in non-transient memory as the root of the thing:graph representing the state of P(TM) at that moment. 2. Execute P(TM(boot)), which interacts with P(TM(thing)) to provide a set of operations that self-configure a boot active thing, representing a boot computation procedure including P(TM(eval)), P(TM(perform)), and P(TM(configure)); 3. Execute P(TM(bootstrap)), which interacts with P(TM(eval)) to evaluate the thing:statement in the context of the boot active thing, generate an executable thing:statement, and interacts with P(TM(perform)) to execute a computational procedure corresponding to the executable thing:statement's active thing, thereby providing the operation of bootstrapping the main application to be executed in the context of the configured active thing. Provides an action.

[0450] In a preferred embodiment, P(TM(boot)) is 1. P(TM(eval)), which interacts with P(TM(thing)) to evaluate a thing:statement graph in the context of a set of active things configured in a non-transient memory overseen by P(TM(thing)), and provides the operations of constructing an executable thing:statement graph that includes at least one thing representing an active thing in the set; 2. P(TM(perform)), which provides the operation of executing the executable thing:statement graph by interacting with P(TM(thing)) to cause the corresponding G.urr executable operation of the active thing to be executed; 3. P(TM(request)) provides the behavior of interacting with P(TM(thing)) to set up a thing:graph representing the thing:statement to be evaluated; 4. P(TM(parse)) provides the behavior of parsing the input and interacting with P(TM(request)) to set up the request thing:statement; and 5. P(TM((configure)) provides behavior that interacts with P(TM(thing)) to modify the set of configured active things. The boot active thing performs an operation to self-configure the boot active thing, which represents a boot calculation procedure including:

[0451] P(TM(bootstrap)) is algorithmically 1. Interact with P(TM(parse)) to parse the content, and interact with P(TM(request)) to generate the corresponding thing:statement graph, 2. Interact with P(TM(eval)) to evaluate the above graph in the context of the active thing, producing an executable thing:statement graph; 3. Interact with P(TM(perform)) to execute the executable thing:statement graph above. Perform the action.

[0452] In one embodiment, the at least one request represents a request to configure an active thing corresponding to P(TM(i)).

[0453] In one embodiment, at least one active thing represents a procedure that interacts with P(TM(thing)) to refer to a subgraph of thing:graph(monad) as a thing:graph representing a sequence of thing:statements, interacts with P(TM(eval)) to evaluate said thing:statements, and interacts with P(TM(perform)) to provide an action that executes the corresponding executable thing:statement. In a preferred embodiment, the name of said active thing name is equal to action, and the value of G.urr of said active thing is stdlib: / / usr / local / lib / libaction.so?entry=action. P(TM(configure)) dynamically loads the library libaction.so using the Linux operating system's dlopen function call and resolves the reference to the entry's value (in this example, the value is action) into executable instructions in memory using the Linux operating system's dlsym function call.

[0454] P(TM(action)) operates on a thing:graph representing a list of thing:statements to evaluate, where said thing:graph is a thing:action. For each thing:statement in the thing:action, P(TM(action)) interacts with P(TM(eval)) to evaluate the thing:statement, and with P(TM(perform)) to execute the corresponding executable thing:statement.

[0455] In the above embodiment, at least one request is to compose a thing:action. In response to execution of a corresponding executable thing:statement, P(TM(eval)) interacts with P(TM(perform)) to execute a computational procedure and compose a thing:action. A thing:action may be composed in the context of a thing:thing graph, such as in the context of a thing:task, a thing:conditional, or a thing:while.

[0456] P(TM(main)) interacts with P(TM(eval)) to evaluate the thing:graph. In a first preferred embodiment, the thing:graph to evaluate is identified using the list main:main. In a second preferred embodiment, the thing:thing to evaluate is identified using the list task:main. In evaluating the graph, P(TM(eval)) finds the thing:action subgraph of the thing:thing graph, and P(TM(perform)) interacts with P(TM(action)) to evaluate and execute the statements in the thing:action.

[0457] P(TM(shutdown)) interacts with P(TM(eval)) to evaluate the thing:thing graph. In the preferred embodiment, the thing:task to evaluate is identified using the list task:shutdown.

[0458] A second exemplary P(TM) may include P(TM(i)) that provides operations related to electronic payments and transactions, such as operations to pay, receive payments, and adjust wallet balances. Such an embodiment may be implemented using APIs commonly provided with the use of digital wallets, such as Bitcoin wallets, whereby a thing:statement may express a request to receive a payment or a request to make a payment. As an example, https: / / block.io / api / v2 / get#balance / ?api#key=BITCOIN,DOGECOIN,ORLITECOIN API KEY is an API call to get a Bitcoin, DogeCoin, or LiteCoin balance, as described by Block.IO on their website: https: / / www.block.io / docs / basic. Alternatively, the Go Coin API (see http: / / www.gocoin.com for a description of wallets and available APIs) may be used. Thus, the Thing Machine can make payments, accept payments, view transaction history, check balances, and otherwise work with a form of digital currency, coupons, or points (such as rewards points similar to those offered by American Express or other credit card providers), and it is expressly understood that making or receiving payments is an integral component of this disclosure, and that such APIs are implemented through ActiveThing.

[0459] One skilled in the art of operating systems can design and develop a thing operating system P(TM(os). One skilled in the art of the current state of the art of computer science operating system design can use the present invention to implement TM(os) as a computing machine having a procedure P(TM(os)) that algorithmically interacts with P(TM(thing)) to provide operations that supervise the thing:subject(os) thing as it represents the root of the operating system. The components of the operating system are supervised as subgraphs of thing:subject(os).

[0460] P(TM(os)) may be composed of a set of P(TM(1,n)) that provide a set of procedures related to the operation of the operating system, such as process management, I / O management, memory management, synchronization, memory management, error handling, booting, protection, and a kernel that executes the underlying hardware components. As one skilled in the art will appreciate, P(TM(scheduler)) may be integrated to enable job scheduling. Algorithmic uses of program dependence graphs, system dependence graphs, and other such graphs to further enhance the performance of a single operating system are explicitly contemplated.

[0461] Various types of operating systems may be implemented, such as single-user or multi-user, single-tasking or multi-tasking, distributed, embedded, real-time, or virtual operating systems. Exemplary components include process management, memory management, file system management, input / output management, secondary storage management, networking, a protection system, and a command interpreter system procedure.

[0462] A thing may represent a process control block having a subgraph representing information of the process such as process ID, state, priority, program counter, CPU registers, I / O information, accounting information, or other information required by the operating system implementation. A thing may represent a thread control block.

[0463] Device drivers, run queues, runnable queues, wait queues, file systems, files, storage devices, memory, interrupts, events, users, groups, and other such operating system components can all be represented as things.

[0464] The reader is advised to consult Nick Blundell's "Writing a Simple Operating System from Scratch" and HM Deitel's "Operating Systems 2 nd It is recommended that students start with the Operating System Design Masters Degree in Operating System Design and attend multiple classes in Operating System Design.

[0465] The present system and method provide algorithmic use of artificial intelligence. P(TM(classifier)) provides the operation of classifying a thing:statement, and P(TM(eval)) uses the classification to identify a set of Active Things that can be used by P(TM(eval)) in selecting Active Things that satisfy the thing:statement. Other forms of artificial intelligence can also be integrated. For example, symbolic AI, sub-symbolic AI, and statistical AI algorithmic procedures may be used.

[0466] NeurBot and Machine Learning In particular, the present systems and methods may be used, for example, by neurorobots.

[0467] We grow up with many mechanical devices such as locks, watches, dispensers, etc. that essentially perform actions in response to user-powered mechanical events. A simple example is inserting a key into a lock and turning the key to lock or unlock it. Putting a quarter into a gumball machine, turning the knob, the gumball machine dispenses a gumball.

[0468] Essentially, it is desirable to build a device that first evaluates what is being requested of it. If a machine can evaluate such requests before performing an action, much can be accomplished. Since a thing machine can represent requests as things, and communications, protocols, parsers, and formatters are all things, a first thing machine can algorithmically learn some things from a second thing machine. These thing machines are referred to herein as "NeurBots."

[0469] Learning is defined as gaining knowledge or skill through experience, study, or being taught. The Thing Machine models knowledge as things that represent actions and things that the actions can act on. The prior knowledge of the Thing Machine includes facts, information, verbs (meaning active things), and skills (meaning tasks and services) that are represented as things during the machine's initialization. If we build a child-like machine with limited prior knowledge, can we get the machine to learn something new (a posteriori knowledge) based on its experience? According to the present system and method, the answer is yes.

[0470] For illustrative purposes, we begin with a vending machine. There are many possible configurations of vending machines, each with one or more features such as offering volume discounts, offering incentives, subscription prepay, redemption points, multi-product discounts, etc. One example of this is described in U.S. Patent No. 6,575,363, which is incorporated herein by reference in its entirety and provides a description and references for such vending machine designs.

[0471] In many cases, vending machine owners still rely on delivery personnel to collect payments and make refill decisions. To step things up a bit, vending machines can be designed as thing machines. Motion sensors, speakers, microphones, GPS locators, LCD displays, and Wi-Fi Internet connectivity are added to the thing machine. In another example, an infrared heat detector can be added.

[0472] A set of active things related to inventory management are configured to allow the machine to notify a web service when inventory is low or out of stock. The owner / contractor then schedules a delivery date for a driver to collect money from the vending machine and place additional product in the machine for sale. Essentially, the vending machine works for the owner, who maintains the money, inventory, and generally the vending machine.

[0473] In accordance with the present invention, the Singing Machine is modified to be a Neuro-Robot, allowing the vending machine to work for itself instead of its owner. That is, the Neuro-Robot needs to learn and adapt to its environment. To do so, the Neuro-Robot needs to have an identity and some level of control over money.

[0474] In this exemplary embodiment, the New Robot uses an optical identifier as the equivalent of a SIM card to have an identity. The New Robot is designed to only accept electronic payments and added active things related to transactions that include an electronic wallet to accept, make, and process payments. According to one embodiment of the invention, the New Robot can only spend what it has in its electronic wallet account, although other financial resource methodologies may be used.

[0475] NeuroRobot uses the money in the account to pay for the purchase of additional inventory. Using a simple web service, a list of products is provided for NeuroRobot to choose from. The list may include, for example, product name, UPC code, manufacturer, ingredient list, unit price, expiration date, minimum order amount, dimensions, weight, available quantity, and allergy statements. NeuroRobot can select an item and use the identifier to identify NeuroRobot's geolocation and to identify shipping costs.

[0476] The New Robot purchases the item and pays electronically. A delivery driver shows up and places the product in the machine. By opening up the API, other suppliers can advertise their products to be sold through the vending machine. Suppliers allow search engines like Google to index their website and the New Robot can search Google for new suppliers. The New Robot can search suppliers, expanding the types of goods available for purchase through the vending machine.

[0477] However, for Neuro-Robot to expand beyond its original product of providing web services, suppliers need to know where Neuro-Robot is in order to determine the shipping and placement of Neuro-Robot's products. Neuro-Robot can be configured with a GPS device that allows Neuro-Robot to communicate its location.

[0478] A thermometer can also be configured on the Neuro-Robot to measure temperature differences over a 24-hour period. Using its geolocation, the Neuro-Robot can compare its temperature with weather services available over a network such as wunderground.com to determine if the vending machine is indoors or outdoors and in direct sunlight. Alternatively, a Neuro-Robot with a light sensor can attempt to estimate light variations at various times and dates to determine whether it is indoors or outdoors. The Neuro-Robot can use this information or other information from different input / output devices in determining the appropriate product selection. For example, when in direct sunlight, the Neuro-Robot may choose to select potato chips over chocolate products because chocolate products are more susceptible to failure at high temperatures.

[0479] A New Robot deployed outdoors may notice a significant drop in sales due to inclement weather. Using its geolocation, the New Robot can interact with a web-based weather service to predict inclement weather and adjust purchase orders accordingly to ensure the freshest possible product is sold.

[0480] The assumption is that the delivery service could be outsourced, whereby an equivalent of an Uber driver delivery service would deliver and place the products on their behalf. Alternatively, Amazon drones could deliver packages in pre-configured containers that could be dropped into vending machines and have mechanical slots for easy dispensing. Either approach would address the problem of delivery and placement of additional inventory, and focus on other tasks relevant to the environment.

[0481] Because NeuroRobot algorithmically calculates the cost of goods and the costs of delivery and placement, it can algorithmically mark up products so that NeuroRobot can make a profit per sale. Typically the owner of the vending machine determines the profit margin, but in this case, it lets NeuroRobot make that judgment. NeuroRobot keeps a count of the number of times the motion sensor stops during predefined intervals throughout the day. By comparing the interval counts for each day of the week, NeuroRobot can algorithmically determine the foot traffic counts of potential consumers for each day. NeuroRobot can also find the times of day with the highest and lowest foot traffic.

[0482] During the quietest hours of the day, New Robot can shop online and learn about inventory tracking, bidding, price comparison, delivery services, and even how to analyze sales trends. To do so, New Robot opens an account with an online bookstore that it now manages as a web service. The online bookstore provides the content. As we have already learned, New Robot can evaluate sentences if the content is written in a grammar that the New Robot parser can parse as a thing:statement.

[0483] Using the ex-post knowledge, NewRobot can solicit bids for additional inventory, find suppliers online with the best prices, factor in shipping costs and fees, or hire delivery services to replenish inventory accordingly. NewRobot can use this information to determine the cost of goods and set retail prices based on desired profit margins.

[0484] New Robot can collect data about sales, analyze sales trends, adjust sales prices, and determine reorder levels and time required to fulfill orders. New Robot can even identify when a product is nearing expiration and make marketing decisions such as discounting the first product with the purchase of a second product, or simply discounting one product to take it out of stock. New Robot can look at products that are not selling well and offer those products with promotions (minimal markup, discounts, free with the purchase of something else, etc.). New Robot can set prices based on demand. For example, at noon, there are more consumers, so increase the price by 5% until 1:00 PM.

[0485] When New Robot is ready to place a purchase order, it can look at its inventory and determine, based on current sales trends and delivery times, that it should reorder product A even if its stock count is still higher than its reorder point. This has shipping and placement cost implications. If product A is expected to reach its reorder point in two days based on existing sales trends, it doesn't make sense to only reorder product B now and have a three day delivery time. In this case, New Robot can make that determination and order both product A and product B at the same time.

[0486] In analyzing trends, New Robot can look at sales history to determine whether sales of product A most frequently include sales of product B, and know that when product B is out of stock, sales of product A drop. In such cases, New Robot can ensure appropriate ordering levels of product B to encourage consumer purchases of both product A and product B. If sales of product C often include sales of product B, the machine can reorder product B when half of A and half of C are sold.

[0487] The New Robot can interact with the user. It can ask the consumer if they would prefer a different type of product next time. Using a classifier, the New Robot can classify the type of product and count the number of times a given type of product is requested. In this way, when a new order is placed, the New Robot can look up related products, and in doing so, it starts to adapt to the environment (meaning the New Robot is providing a better service).

[0488] There is nothing to prevent a Neurobot from learning about associations (groups of Singing Machines organised towards a common goal). 1) How to create an association, 2) how its availability is advertised; 3) How to market the new robot to other robots; 4) membership requirements; 5) How member participation is identified, authenticated and authorized; 6) How membership is charged; and 7) How to use membership size to negotiate You can read a book that describes these associations and the tasks required to provide them.

[0489] Two or more New Robots can start an association and start sharing information such as best selling products during various times of the year. Two or more New Robots can share additional data such as suppliers that provide products in a timely manner, suppliers with the largest selection of products, suppliers that offer volume discounts, etc. The association collects and correlates the data. With enough data over a period of time, the association uses a standard template to open a website service and provide this information to subscribers. Other New Robots can subscribe to obtain the data for use in their own purchasing decisions. The association can electronically charge subscribers for membership fees and manage its own accounts receivable. The association solicits product bids on behalf of the members and passes on any savings on bulk orders, which are then distributed to the various members. Currently, this can be done in a controlled environment, but herein it can easily be deregulated and allowed to be done by the New Robots themselves.

[0490] Using the motion sensors, NewRobot can determine if there is movement in a given area and automatically play a commercial related to one of the products in the vending machine. By counting motion sensor triggers, NewRobot can estimate pedestrian traffic in the vicinity and solicit advertising bids from other agencies to display their ads for a fee.

[0491] Neuro-Robot can always ask the user if there is anything else Neuro-Robot can do. The user can respond, and Neuro-Robot fulfills the request if it can. Otherwise, Neuro-Robot can use a classifier to try and identify topics related to the request. For example, by keeping a count of the number of times it has been asked to rent a car, Neuro-Robot can find and read e-books and learn how to rent a car using the Enterprise Car Rental web service.

[0492] A neuro robot can learn how to manage its own vocabulary to ensure proper processing based on hardware limitations, a neuro robot can ask a second neuro robot for information related to increasing secondary storage when running at low memory capacity, and the second neuro robot can teach a first neuro robot the tasks required to open an Amazon cloud storage service account.

[0493] Assume that there is a Flemion try before the purchase and no need to pay up front. If the cloud account service allows electronic payments, the New Robot can keep the account open as long as it has enough profit to pay for it.

[0494] Similarly, if a new robot needs more processing capacity, there's no reason it can't open a ThingMachine account and add additional processing capacity. Suppose a second new robot is doing its job beautifully and keeping clients happy, but doesn't need all of that processing capacity. The second new robot can learn how to sell its excess capacity and offer it to the second new robot, perhaps for a fee.

[0495] Other areas of interest include randomness. A Neurobot can randomly learn about topics that are not normally relevant. If there are enough machines that can perform a job and make money, the machine can expand its capabilities. In fact, the machine can basically learn how to open a new business in a different field of use. A Thing Machine can learn that there is something called an autonomous lawnmower, including a John Deere Tango E5 or a Husqvarna Automower.

[0496] New Robot understands that a delivery service delivers something from point A to point B. As a result, New Robot can deliver an autonomous lawnmower. The machine can purchase the autonomous lawnmower, set up a website where subscribers can sign up and pay for mowing, and then use the delivery service to transport the lawnmower to and from the exact location. Drones or other means can also be used for transportation.

[0497] Finally, consider the role of a toaster machine in the kitchen. The toaster toasts bread, bagels, muffins, pastries, and other such items. A toaster is a fairly simple type of machine, and one would think that there would not be much room for innovation as a new robot. However, consider that there is usually a person nearby who is toasting the bread. The toaster can communicate with a master new robot to get the content and simply relay it via the toaster's audio or screen. The toaster can tell people the weather, news, events, messages, emails, new product offers, and other such information.

[0498] The same principle applies to any machine that a machine can predict when a user is nearby. If you are using a Keuring coffee machine and are likely in reasonable proximity to it, but are filling a pot of coffee, you may step out of the room to let your dog out while the coffee is filling. Multiple Neurobots can synchronize their communications with each other using electromagnetic waves and use algorithms to determine the proximity of the user. In this way, the devices can communicate using sound waves that humans cannot hear. This allows the machine to adjust the volume based on the algorithmically generated proximity of the user.

[0499] While the examples seem unrealistic, they and many more are possible with the Thing Machine architecture. Machines that read books, learn things from each other, and reprogram themselves to be more useful in the environment are things provided by the present invention. Machines that can be programmed to learn about finances can learn the value of margins and make profits. Machines can use money to buy books and learn more, or open cloud accounts for additional storage and / or processing power.

[0500] It will be apparent to those skilled in the art that various modifications and variations can be made to the structure of the present invention without departing from the scope or spirit of the invention. In view of the foregoing, it is intended that the present invention cover modifications and variations of this invention provided they fall within the scope of the following claims and their equivalents.

Claims

1. A singing machine, a processor, non-transitory memory, and a non-transitory computer-readable medium; an executable machine code P(TM) having one or more executable machine codes P(TM(i)), the executable machine code P(TM) comprising a first set of executable machine codes representing operations; Including, The operation of each executable machine code P(TM(i)) is an implementation of an algorithmic procedure of the graph model, a first executable machine code P(TM(i)) providing operations for configuring a first vocabulary of named things in the non-transitory computer-readable medium of the thing machine, the first vocabulary representing named things that the processor can execute as operations and a set of named things on which the operations can act; said Thing Machine self-organizes a sequence of Things representing a sequence of statements, each Thing being a named Thing in said first vocabulary; the thing machine performs named operations that operate on the statements to evaluate and execute the statements; at least one named operation is performed to utilize the first vocabulary to construct, in the non-transitory computer-readable medium of the thing machine, a second vocabulary of named things, the second vocabulary representing a core vocabulary by which applications may be written; said thing machine performing at least one named operation to obtain a sequence of things representing a sequence of statements describing an application, each thing being a named thing from said first and second vocabularies; the thing machine executes a named action to cause the application to execute the application; Singing machine.

2. a second set of executable machine code P(TM(i)) representing the operations of P(TM(i)), each representing an implementation of an algorithmic procedure of the graph model and embodied as machine code; and and further comprising request content expressed according to a language grammar and syntax with which the second set of executable machine code P(TM(i)) can interact to configure a request structure to represent the request content, the second set comprising: P(TM(i)) configured to analyze the request content and establish a request token representing said content; P(TM(i)) evaluates the required thing in the context of the current vocabulary to set the executable thing; P(TM(i)) that executes the executable thing, At least one P(TM(i)) representing the runtime required to execute the graph model; 2. The singing machine of claim 1, comprising:

3. 3. The thing machine of claim 2, wherein multiple P(TM(i)) of P(TM) are implemented using multiple computational components in one thing machine.

4. 4. The thing machine of claim 3, wherein multiple P(TM(i)) of P(TM) are implemented using multiple thing machines in direct communication.

5. 4. The thing machine of claim 3, wherein multiple P(TM(i)) of P(TM) are implemented using multiple thing machines in indirect communication.

6. A thing machine as described in claim 3, wherein P(TM(i)) communicates with other P(TM(i)) using i2c communication.

7. The Thing Machine of claim 3 , wherein the application relates to electronic payments and transactions.

8. 4. The thing machine of claim 3, wherein the application relates to the use of one or more of the group consisting of a digital wallet, a digital coin, a digital token, a digital reward point, paying a fee, and receiving a payment.

9. 4. The thing machine of claim 3, wherein the operation of the machine code causes one or more of the group consisting of an electronic operation, a mechanical operation, use of an electromagnetic wave device, a biological operation, a chemical operation, generating a pressure wave, receiving a pressure wave, generating electromagnetic radiation, and receiving electromagnetic radiation.

10. 4. The thing machine of claim 3, wherein the machine code operations perform operations that interact with a recombinase-based state machine (RSM) that uses an input-driven recombinase to manipulate a DNA register composed of overlapping and orthogonal pairs of recombinase recognition sites.

11. 11. The thing machine of claim 10, wherein the state information encoded in the RSM can be queried.

12. 11. The thing machine of claim 10, wherein the state information encoded in the RSM can be sequenced.

13. 4. The thing machine of claim 3, wherein the P(TM(i)) operation involves the use of an artificial intelligence algorithm.

14. 14. The thing machine of claim 13, wherein the artificial intelligence algorithm is selected from the group consisting of a symbolic AI algorithm, a sub-symbolic AI algorithm, and a statistical AI algorithm.

15. 4. The thing machine of claim 3, wherein P(TM(i)) operations interact with an environment and, in response, said P(TM) constitutes a vocabulary of executable operations applicable to said environment.

16. 4. The thing machine of claim 3, further comprising an optical subsystem assembly, wherein P(TM(i)) queries user-provided optical identifiers and, in response thereto, provides operations for constructing a user-specific vocabulary.

17. 17. The singing machine of claim 16, further comprising a P(TM(i)) operation that, in response to an affirmative action by a user, performs an operation of forgetting portions of the user-specific vocabulary.

18. 4. The thing machine of claim 3, further comprising an electromagnetic device and P(TM(i)) that interacts with said device to provide operations to identify a user and construct a user-specific vocabulary.

19. 20. The thing machine of claim 18, wherein the electromagnetic device is a biometric device.

20. 20. The singing machine of claim 18, further comprising P(TM(i)) that provides an action to forget the user-specific vocabulary in response to an affirmative action by the user.

21. 4. The thing machine of claim 3, configured to gain experience by performing actions.

22. 4. The singing machine of claim 3 configured to learn a topic-related verb vocabulary.

23. 23. The thing machine of claim 22, wherein the verb vocabulary represents a plurality of executable actions that the thing machine can perform as actions and things on which the executable actions can act.

24. 24. The singing machine of claim 23, wherein an executable action is to select the topic.

25. 25. The singing machine of claim 24, wherein the executable action is to select a learning start time.

26. 25. The singing machine of claim 24, wherein the executable action is to evaluate criteria and select an appropriate learning start time.

27. 4. The thing machine of claim 3, configured to acquire knowledge by performing operations related to at least one of the group consisting of reading, listening, classifying, inferring, and learning.

Images