WO2021226771A1

WO2021226771A1 - Method and system for creating user-defined programming cards

Info

Publication number: WO2021226771A1
Application number: PCT/CN2020/089518
Authority: WO
Inventors: Zheng Shi; Hongge ZHOU; Hanyin YE; Jiong LI; Yao TANG; Xingyi GONG
Original assignee: Zheng Shi
Priority date: 2020-05-11
Filing date: 2020-05-11
Publication date: 2021-11-18

Abstract

The present invention provides method and system for creating user-defined programming cards and user programs. A programming user performs touch gesture upon a user interface to formulate a first instruction for a change in the value of a first variable controlled by a first actuator embedded in a first physical block, and the first instruction is encapsulated into a first Method by a computer. The UID embedded in a first physical card is read and associated with the first Method to create a first Method card. Subsequently, when the first Method card is selected, the first actuator is directed to execute the first Method, comprising implementing the change in the value of the first variable.

Description

METHOD AND SYSTEM FOR CREATING USER-DEFINED PROGRAMMING CARDS

TECHNICAL FIELD

The present invention and its embodiments relate to method and system for creating user-defined programming cards and user programs.

BACKGROUND

Graphical programming provides young children with an attractive way to learn programming. It converts programming concepts to graphics that can be displayed on a screen. Children drag graphics and enter parameters to finish the whole process of programming. Tangible programming (or physical object programming) allows children to use physical objects to build a program. The difference between tangible programming and graphical programming is that tangible programming is not restricted by computer screens. Tangible programming allows a young programmer to interact with physical objects, and converts logic expressed by physical objects to programming logic. Through a tangible programming system, children learn to understand programming concepts more intuitively. Programs are no longer lines of abstract codes, but combinations of physical objects that are natural and intuitive to children. By combining physical objects, children can finish the work that otherwise needs to be typed using a keyboard in programming languages. The characteristic of tangible programming determines that it is more suitable for children to learn programming.

Current tangible programming implementations allow an end-user, a child for example, to create a program that a single "physical block" then executes. For the purpose of this patent application, a physical block refers to a physical structure that is electrically connected together, sometimes rigidly, with a single central control and communication unit, and one or more actuators. Examples of a physical block may be a humanoid robot or a robotic car that is very much commercially available, and some robots require an end-user to assemble parts into a functional whole. Examples of an actuator may be a motor, an LED light, or a buzzer, that are connected with a wire to the central control and communication unit.

Current tangible programming implementations allow a child to create a program with physical objects, most often programming cards, either on a screen, or on an interactive surface that is a non-screen device, or on a flat surface that is being monitored by a camera device. Such program is then transmitted to the physical block for execution. The central control unit within the physical block receives the program and directs an actuator within the physical block to actuate an action, such as turning on LED light of a particular color, or moving the entire physical block in a certain direction, or lifting the arm of humanoid robot.

One limitation of the current implementations of tangible programming with physical objects is that an end-user is limited to program the many functions of manufacturer-designed physical block. There is simply very limited learning or fun for a child to keep changing the color of the robot's LED light or the direction of the robot's movement or the lifting of the robot's arm, and little room for a child to express her and his own imagination.

Another limitation of the current implementation of tangible programming with physical objects is that, in situations that involve multiple end-users, an action programmed by one end-user cannot serve as either pre-condition or consequence of an action programmed by another end-user. For example, current implementations, with one physical block as the single programming target, cannot accommodate the creation of a turn-by-turn battle game between two end-users, whereby, each end-user programs an action of the robot s/he controls, with the execution of such action conditional upon the action of the other robot programmed by the other end-user.

Another limitation of the current implementation of tangible programming with physical objects is that, it cannot allow a group of users to create a single program with multiple physical blocks executing actions, whereby the actions have relationships of interdependence among them. For example, current implementations do not allow a group of users to program a miniature city, whereby traffic lights turn green and red, whereby cars move or stop according the color of the traffic lights, and figurines move around, greeting each other as they approach one another.

Another limitation of the current implementation of tangible programming with physical objects is that, the ways for children to input values of an actuator within a block is neither intuitive nor direct. Most often, a child needs to select a value from a drop-down menu on a computer screen. Such processes are well suited for grownups for better productivity, but not suited for children who are learning by playing.

Another limitation of the current implementation of tangible programming with physical objects is that, a child cannot organize the many actuators at will, to create novel and imaginative combinations, since manufacturers typically dictates what the final "physical block" would look like and how it would function. For example, while some commercially available products allow a child to customize the final build of a functional humanoid robot, none allows a child to turn the many parts of the humanoid robot into entirely something else.

There are numerous limitations that characterize the current implementations of tangible programming with physical objects, and that are not described here.

SUMMARY OF INVENTION

The present invention resolves limitations of prior art, some of which are highlighted in the background section, by providing method and system for creating user-defined programming cards and user programs.

In accordance with one embodiment of the present invention, the method for creating a user-defined Method card includes:

performing, by a programming user, touch gesture upon a user interface to formulate a first instruction for a change in the value of a first variable, wherein, the first variable is controlled by a first actuator embedded in a first physical block among a plurality of physical blocks, with no physical block electrically connected with another physical block;

encapsulating the first instruction into a first Method;

reading, by a reader, the UID embedded in a first physical card, and associating the said UID with the first Method to create a first Method card;

selecting, subsequently and by the programming user, the first Method card; and

directing, via wireless communication means, the first actuator to execute the first Method, comprising implementing the said change in the value of the first variable.

In accordance with another embodiment of the present invention, the method further includes:

performing, by a programming user, touch gesture upon a user interface to formulate a second instruction for changes in the values of the first variable and a second variable, wherein, the second variable is controlled by the first actuator, for example, the first variable and the second variable being the color and the brightness of an LED light; or by a second actuator embedded in the first block, for example, the first variable is the color of an LED light, while the variable is rotation speed of a motor, both of the LED light and the motor are embedded in the first block; or by an actuator embedded in a second block, for example, the second actuator motor is embedded in a second block;

encapsulating the second instruction into a second Method by a processor;

directing, by a processor, the execution of the second Method, comprising implementing the said changes in the values of the first variable and the second variable.

In accordance with an embodiment of the present invention, the method further includes:

associating the UID of a second physical card with the first block and the second block referenced in the second Method to create a first Object card, as a single representation for both the first block and the second block. In this embodiment of the present invention, an end-user is enabled to create an Object that previously has not existed, over the programming process, with the Object being defined as a composite of two physical blocks.

implementing, by the first actuator, the said change in the value of the first variable, while the said change is being formulated by the touch gesture, for the purpose of providing visual feedback to the programming user;

performing, by the programming user, a modified touch gesture based on such visual feedback, in formulating the first instruction.

In this embodiment of the present invention, an intuitive and iterative process is enabled, for a child to see the result of his or her action immediately, and make modifications at the same time, to achieve the final effect that she or he desires to see.

capturing a parameter of the touch gesture;

incorporating the parameter into the first instruction;

wherein, the touch gesture could be touch gesture by finger or stylus on a capacitive sensor array, touch gesture by OID reader on a sheet printed with OID code, or touch gesture by OCR reader on a sheet printed or written or drawn with visual characters;

wherein the said parameter could be multiplicity of touch points, repetition of touches, intensity, duration, direction, speed, or acceleration.

In this embodiment of the present invention, a correlation between a parameter of the touch gesture and a value or a change of value of an actuator could be established, or pre-established. Over the course of a programming process, a child is therefore empowered to essentially define the Properties of a Method in the user program she or he is developing, using touch gestures that are simple, intuitive and powerful, as opposed to using dropdown menus from a screen-based application.

providing an audio element by a programming user;

incorporating the audio element into the first Method.

This embodiment of the present invention further integrates children’s voice, their own voice or sounds that they obtained from another source, into the program that they are developing.

In accordance with another embodiment of the present invention, a system for creating a user-defined Method card includes:

a plurality of physical blocks, each embedded with an actuator that controls a variable, and no physical block electrically connected with another physical block;

a user interface;

a plurality of physical cards, each embedded with a UID;

a reader that reads the UID of a physical card, upon the physical card being brought to proximity to the reader;

a computer;

wireless communication means between the computer and a physical block;

wherein, a programming user performs touch gesture upon the user interface to formulate a first instruction for a change in the value of a first variable;

wherein, the computer is configured to encapsulate the first instruction into a first Method, and associate the first Method with the UID of the first physical card to create a first Method card;

wherein, subsequently, a programming user selects the first Method card;

wherein, the computer is configured to direct the first actuator to execute the first Method, comprising implementing the said change in the value of the first variable.

The present invention also discloses method and system for creating a user program.

In accordance with one embodiment of the present invention, the method for creating a user program includes:

creating a Method card, by associating the UID of a physical card with a Method that encapsulates an instruction for a change in the value of a variable controlled by an actuator embedded in a physical block;

wherein, the said physical card is among a plurality of physical cards, each embedded with a UID, and the said block is among a plurality of physical blocks, each embedded with an actuator, and none of the blocks is electrically connected to another block;

placing, by a programming user, multiple Method cards and system programming cards together, to form a programming structure;

wherein, each system programming card is associated with a system programming element;

reading, by a reader, the UIDs of the Method cards and system programming cards in the programming structure;

transforming the programming structure into an executable user program;

directing the execution of each of the Methods referenced in the user program, comprising implementing the said changes of values by each of the actuators and blocks referenced in the said Methods.

In this embodiment of the present invention, one or more programming users are enabled to create a user program that comprise execution by multiple actuators and multiple blocks, all by forming a programming structure with programming cards, some of which are pre-defined as in the case of system programming cards, some of which are defined by one or more programming users, as in the case Method cards, and Object cards as well. A child is no longer limited by having to program the many functionalities of a single physical block in ways that are pre-designed by the manufacturer, and is empowered to create a program with multiple characters, multiple storylines, and multiple actions executed by multiple actuators and blocks, in whatever sequence of logic or time as the child desires.

integrating, by a cloud server, multiple user programs created by more than one programming user, or read by more than one reader, to create a master user program, for purposes that comprise debugging and sequencing said instructions.

In this embodiment of the present invention, collaboration among children is enabled, whereby each of them is able to create a user program, and a cloud server integrates all user programs.

associating rights and restrictions regarding an actuator or a physical block with an identity among a plurality of end-user identities;

assuming an identity by a programming user;

implementing, and informing the programming user of, rights and restrictions associated with the said identity regarding the said actuator or said block.

In this embodiment of the present invention, and as the cloud server is configured to integrate multiple user programs, it is possible that issues regarding sequencing of the execution of Methods created by multiple programming users may contradict or interfere with one another. It is also possible that one particular actuator or a block is utilized by more than one programming user. As such, the cloud server is configured to maintain a database of a plurality of identities, and rights and restrictions regarding an actuator or a block, with such rights and/or restrictions assigned differently to each of the identities.

verifying a pre-condition for a Method before executing the said Method;

directing the execution of a subsequent Method after executing the said Method;

wherein, the said Method and the subsequent Method have a causal relationship.

In this embodiment of the present invention, external logic regarding the executions of Methods are incorporated into a user program, without input from a programming user, for the purpose of providing ease of programming, stimulating end-user interests, and/or teaching an end-user meaningful lessons.

In accordance with another embodiment of the present invention, a system for creating a user program includes:

a plurality of physical blocks, each embedded with an actuator that controls a variable and no physical block electrically connected with another physical block;

a plurality of physical cards, each embedded with a UID;

a plurality of system programming cards, each embedded with a UID and associated with a system programming element;

a computer;

wherein, a programming user creates a Method card, by associating the UID of a physical card with a Method that encapsulates an instruction for a change in the value of a variable controlled by an actuator embedded in a physical block;

wherein, a programming user further places multiple Method cards and system programming cards together, to form a programming structure;

wherein, the reader reads the UIDs of the Method cards and system programming cards in the programming structure, and the computer is configured to transform the programming structure into an executable user program, and direct the execution of the user program, comprising implementing said changes of values by each of the actuators and blocks referenced in the said Methods.

BRIEF DESCRIPTION OF THE DRAWINGS

To better illustrate the technical features of the embodiments of the present invention, various embodiments of the present invention will be briefly described in conjunction with the accompanying drawings. It should be obvious that the drawings are only for exemplary embodiments of the present invention, and that a person of ordinary skill in the art may derive additional drawings without deviating from the principles of the present invention.

FIG. 1 is an exemplary schematic diagram illustrating the process flow for creating a user-defined Method card in accordance to one embodiment of the present invention.

FIG. 2 is an exemplary schematic diagram illustrating a system for creating a user-defined Method card in accordance with one embodiment of the present invention.

FIG. 3 is an exemplary schematic diagram illustrating a system for creating a user-defined Method card and Object card in accordance with one embodiment of the present invention.

FIG. 4 is an exemplary schematic diagram illustrating the process flow for creating a user program in accordance to one embodiment of the present invention.

FIG. 5 is an exemplary schematic diagram illustrating a system for creating a user program in accordance with one embodiment of the present invention.

FIG. 6 is an exemplary schematic diagram illustrating a causal relationship between two Methods executed by two separate blocks in accordance with one embodiment of the present invention.

FIG. 7 is an exemplary schematic diagram illustrating a system for creating a user-defined Method card using an optical identification reader, in accordance with one embodiment of the present invention.

FIG. 8 is an exemplary schematic diagram illustrating a system for creating a user program using an optical identification reader, in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to various embodiments of the invention illustrated in the accompanying drawings. While the invention will be described in conjunction with the embodiments, it will be understood that this is not intended to limit the scope of the invention to these specific embodiments. The invention is intended to cover all alternatives, modifications and equivalents within the spirit and scope of invention, which is defined by the apprehended claims.

Furthermore, in the detailed description of the present invention, specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits are not described in details to avoid unnecessarily obscuring a clear understanding of the present invention.

Before proceeding to describing the various embodiments of the present invention, definitions for key words and expressions will first be made.

For the purpose of this patent application, “user programming elements” such as Method, Object, Property, or Event, are defined in the same manner as they are commonly used in defining a programming language. Further, a programming user is able to create or modify a portion of such programming elements.

For the purpose of this patent application, “system programming elements” are defined as: control, operator and comparators with the programming user being able to utilize these programming elements but not able to alter the definition and usage of these programming elements. Control comprises of but is not limited to: delay, loop, loop forever, loop until, then, if then else, exit program. Operator comprises of but is not limited to: add, subtract, multiply, divide, exponent, set, color channel, build string, random integer, random float, square root, round, floor, ceiling, absolute, sign, minimum, maximum. Comparator comprises of but is not limited to: equal, not equal, less than, less than or equal, greater than, greater than or equal, and, or.

A “template program” is a program generated by a vendor as a starting point for a programming user to further build up. A “user program” is defined as a program that the programming user creates by adding code into a template program.

A "programming user" is an end-user that uses the system or method described in this present invention for the purpose of creating a user-defined programming card, or creating a user program. Once a programming user has created a user program, an operating user, who may or may not be the same as the programming user, uses the user program as created by the programming user. A programming user and/or an operating user is referred to as an end-user in this present invention.

In accordance with one embodiment of the present invention, a system for creating a user-defined Method card includes multiple physical blocks, a touch-based user interface, multiple physical cards, a reader and a computer. Each block is embedded with an actuator that controls a variable, and each card is embedded with a unique ID. Once a card is placed in proximity to the reader, the reader reads the unique ID of the card. And a wireless communication means embedded within the computer and within a block enables the wireless communication between them.

For the purpose of this patent application, a physical card is a disc like structure that has a unique machine-readable identification chip, for example, an RFID tag, placed inside it. Such a physical card is an example representation of a unit of instruction that allows a programming user to build a programming structure and to get the programming structure translated into a machine-executable user program. It should be obvious to those who are skilled in the art that other types of design and technology of "physical card" could be employed to replace the physical card described in the present invention, for example with optical ID and optical sensor detection, and these other types of implementation of the physical card are all within the scope of the present invention.

For the purpose the present patent application, a Method card represents a Method and an Object card represents an Object, and they are individually or collectively referred to as programming card (s) .

For the purpose of this patent application, a physical block refers to a physical structure that is electrically connected together, sometimes rigidly, with a single central control and communication unit, and with one or more actuators. The electrical connection among sub-components of a physical block allows the transmission of electrical power as well as electrical data signals. An example of commercially available programming product, whereby a central processing unit has multiple outlets that can connect to multiple actuators such as motors or LED lights, and whereby each of the actuator is controlled by the same central processing unit, is regarded as a single physical block, for the purpose of this patent application.

For the purpose of this patent application, a physical block works individually, which means that each block does not electrically connect to another block, is capable of receiving an instruction via wireless means, is capable of an action based on an instruction received via wireless communication means, independent of any other block. Examples of a physical block may be a figurine, a robot or a robotic car that is very much commercially available, and some robot requires the end-user to assemble parts into a functional whole. For example, a humanoid robot toy may be comprised of a CPU, motors, sensors, and lights, etc., and is nonetheless regarded as a single physical block, for the purpose of this present patent application, if such a robot has a single central control unit, that receives instructions from an external source, and that directs the actions of actuators embedded inside the robot, via wired transmission of power and data.

For the purpose of this patent application, an actuator is a single function component, whereby the function may be roughly described as creating a physical effect that is easily discernible to the naked eye or ear of an observer. As a result, for the purpose of this patent application, the definition of "actuator" is expanded to include the functions of changing the operating state of a light source, broadcasting a sound file, nebulizing water into fine mist, etc. For example, an actuator could be a motor, a nebulizer, an LED light, or a speaker, etc.

Each physical block (the terms "block" and "physical block" are used interchangeably in this patent application) has, embedded within it, one or more actuators that control variables, and each actuator controls one or more variables. The term variable is used in the context of describing the function of an actuator, and not in the context of programming. In the context of programming, a variable is typically referred to as a "Property" of an "Object" .

For the purpose of the present invention, actuators may be LED lights, motors, nebulizers, etc., and variables may be, but not limited to, brightness or color of light, the direction, speed or distance of movement, the content or volume of sound, or the combination of variables herein.

For an actuator that is a water nebulizer, it may have a single primary variable -amount of fine mist generated per unit of time, and such amount may either stay constant, or change over time. It may have secondary variables related to actual usage, e.g., the direction at which it is directing the stream of fine mist, the aperture through which the fine mist is released into the ambient atmosphere.

For an actuator that is an LED light, it may have two primary variables -brightness and color, whereby such each may stay constant, or change over time.

For an actuator that is a motor, it may have three primary variables -direction of rotation, number of cycles of rotation, and speed at which it rotates, and the value of each of the three variables may change over time. It may also have secondary variables related to actual usage, e.g., the spatial orientation of the axis of the motor.

The value for a variable controlled by an actuator may be a constant or a function of time, temperature, distance, etc. Each block with an actuator is capable of executing multiple Methods, since the actuator may have many variables and each variable may have many values. A block may be embedded with multiple actuators. For example, the execution of a volcanic eruption Method needs two actuators in the block, a nebulizer and an LED light.

The values of variables are chosen to create a sensory (visual, audio, tactile, etc. ) effect that substantially simulates a real-world behavior, phenomenon or event, e.g., volcano eruption, wind power generation, or earthquake, etc.

Other terms may be used to define the same concepts. For example, terms such as data, data fields, attributes, are also often used interchangeably with the term Property. The term “function” is often used instead of “Method” . It will be obvious to those are who are skilled in the art that the terms used should not be conceived as restrictive in any way and other terms also commonly used in the art may be used interchangeably.

Embodiments described in Figs. 2-3 and Figs. 5-6 utilize an interactive board, either a screen-free device or a screened device. In these embodiments, references were made for an interactive board to be equipped with a capability to read an RFID tag embedded in a physical card, and for a programming user to perform touch gesture with fingers upon a touch-based user interface such as a touch screen with capacitive sensor arrays, for generating an instruction.

The process flow for the present invention has the following steps:

Step 101: performing, by a programming user, touch gesture upon a user interface to formulate a first instruction for a change in the value of a first variable, wherein, the first variable is controlled by a first actuator embedded in a first physical block among a plurality of such physical blocks with no physical block electrically connected with another physical block;

Step 102: encapsulating the first instruction into a first Method;

Step 103: reading, by a reader, the UID embedded in a first physical card, and associating the said UID with the first Method to create a first Method card;

Step 104: selecting, subsequently and by the programming user, the first Method card;

Step 105: directing, via wireless communication means, the first actuator to execute the first Method, comprising implementing the said change in the value of the first variable.

The above process can be better illustrated in Fig. 2, an exemplary schematic diagram illustrating a system for creating a user-defined programming card in accordance with one embodiment of the present invention.

As shown in Fig. 2, the system includes an interactive board 200, a physical sheet 210 placed on the interactive board 200, multiple physical block 220, and multiple physical cards 230. In accordance with an embodiment of the present invention, each of the physical blocks is embedded with one or more actuators, a wireless communication means, and a power source. In accordance with an embodiment of the present invention, each of the physical cards is embedded with a radio frequency tag, e.g. RFID or NFC tag that can be read by a reader embedded in the interactive board 200.

The interactive board 200 might be an interactive device without a screen, such as Beyond Tablet. It may also include a screen, e.g., a touch-screen tablet or display or TV with RFID or NFC capability. Furthermore, interactive board 200 may be separated into two devices, a first device that provides the RFID or NFC reader capability, and a second device for capturing the touch gesture of a programming user. For the purpose of brevity, we have illustrated this embodiment whereby the reading of the physical card and the capture of touch gesture of a programming user are functionalities provided by a single interactive board 200. The interactive board 200 is typically embedded with a processor. In accordance with one embodiment of the present invention, the physical sheet 210 serves as a touch-based user interface; in another embodiment of the present invention, it is replaced by a touch screen. In accordance with another embodiment of the present invention, programming users may directly perform a touch gesture upon the interactive board 200, which means that the interactive board 200 could also serve as a user interface. In accordance with yet another embodiment of the present invention, the interactive board 200 provides the RFID or NFC capability, while a separate screen device provides the touch-based user interface. The touch gesture comprises of, but not limited to, simple touch to select a value, two-finger touch to select two values at the same time, long press for sustaining a particular value, slide for transitioning from one value to another value, and drawing a path of movement. These touch gestures are described here as illustrative examples and should not be regarded as an exhaustive list of touch gestures covered by the scope of the present patent application.

A touch may only select one value of a variable, and the value may comprise intensity and/or duration of the touch. For example, a simple touch and a long press will certainly formulate different instructions for changes in a value. Likewise, a single touch and a touch with multiple fingers may also lead to different value changes since the multiplicity of touch points are different. Repetition of touches and sliding touches upon different locations may also provide more values or change of values. And drawing a path of movement may enable the instructing of value change of variables such as direction, speed and acceleration.

The block 222 among the multiple physical blocks 220 is embedded with a motor (i.e., an actuator) that controls at least one variable, for the purpose of simulating an earthquake accompanying a volcanic eruption. As stated earlier, the variables controlled by the motor might be direction of rotation, number of cycles of rotation, and rotational speed of the motor.

A programming user interacts with the physical sheet 210 by touching it clockwise or counterclockwise around a fixed point on the physical sheet 210, to formulate an instruction for a change in the value of a variable, e.g., change in direction of rotation of the motor actuator embedded in the block 222. And the instruction is subsequently encapsulated into a Method called “earthquake” . It should be noted that the touch gestures performed upon the user interface could be either a single touch action or a series of touch actions.

Once a programming user (might be the same, but not necessarily, programming user who formulates the “earthquake” Method) places a card 232 among the multiple cards 230 on the interactive board 200, the unique ID embedded in the card 232 is read and associated with the “earthquake” Method to create an “earthquake” Method card 232. A programming user may further make a visual mark on the “earthquake” Method card 232.

Subsequently, if the “earthquake” Method card 232 is placed on the interactive board 200 by a programming user, a processor is configured to direct, via wireless means, the motor embedded in the block 222 to execute the “earthquake” Method, by moving around clockwise or counterclockwise for changes in the direction of its rotation, according to the instruction having been formulated by the touch gesture.

Similarly, a programming user may formulate an instruction for another actuator in another block to perform an action, and the execution of such instruction has no effect upon block 222 whatsoever. A programming user is therefore enabled to pick and choose any block she or he desires to program, with such programming executed by that particular block, independent of any other block.

Fig. 3 is an exemplary schematic diagram illustrating a system for creating a user-defined Method card and Object card in accordance with another embodiment of the present invention.

A block 322 among multiple physical block 320 is embedded with an LED light that controls a first variable, the color of the light, for the purpose of simulating a volcanic eruption. A programming user interacts with a physical sheet 310 by sliding upon it back and forth to switch among several colors to formulate an instruction for a change in the color of the light. And the instruction is subsequently encapsulated into a “volcanic eruption” Method.

Once a programming user places a card 332 among the multiple cards 330 on the interactive board 300, the unique ID embedded in the card 332 is read and associated with the “volcanic eruption” Method to create an “volcanic eruption” Method card 332. A programming user may further make a visual mark on the “volcanic eruption” Method card 332. Subsequently, upon the “volcanic eruption” Method card 332 being placed on the interactive board 300, the LED light embedded in the block 322 is directed to execute the “volcanic eruption” Method to change the color of the light, according to the instruction formulated by the programming user with the touch gesture.

In one embodiment of the present invention, while the change in the value of a variable is being formulated by a specific touch gesture, as seen above, the said change is implemented, to provide visual feedback to the programming user, for the purpose of formulating an effect desirable to the programming user. Such said implementation of the value changes may happen in real time, or may happen in a turn-by-turn type timing whereby a programming user performs a touch gesture, implement it to see its effect, and changes as s/he desires. This process enables the programming user, for the purpose of figuring out the desirable values of a variable, to visually inspect the result of the touch gesture upon the actions executed by the relevant block, and decide on how the touch gesture could further be formulated and/or modified. Thus, the programming user could adjust her/his touch gesture, based on the visual feedback, to formulate a modified instruction. To be specific, the change in the color of the light, as a result of a specific touch gesture, is by all means visible to the programming user who could change the manner in which the colors of the light changes, based on the real time visual feedback, to choose the color of the light s/he likes.

In accordance with one embodiment of the present invention, the interactive board 300 is configured to capture a parameter of the touch gesture, and incorporate the parameter into an instruction for an actuator to change the value of a variable. As mentioned earlier, the parameters may be different for different types of touch gestures, and could be selected from a group comprising multiplicity of touch points, repetition of touches, intensity, duration, direction, speed or acceleration.

The changes in the values of a second variable could also be formulated and then encapsulated into the “volcanic eruption” Method. The second variable could be controlled by the same actuator, or by another actuator embedded in the same block 322, or by an actuator embedded in another block 324 among the multiple blocks 320.

In accordance with one embodiment of the present invention, a second variable, the brightness of the light, is controlled by the same actuator, i.e., the LED light. The programming user can control the value of this variable by touching the physical sheet 310 up and down vertically. Thus, the change in the values of both variables, i.e., the color and the brightness of the light, is formulated into the “volcanic eruption” Method that encapsulate the instructions of change of values of the first (color) and the second (brightness) variables controlled by the same actuator 322. A “volcanic eruption” Method card 332 is then created that allows a programming user to change both the color and the brightness of the LED light with a single actuator LED light within a single block 322.

In accordance with another embodiment of the present invention, another actuator, i.e., a water nebulizer, is also embedded in the block 322. The programming user can control the amount of fine mist generated per unit of time by touching the physical sheet 310 up and down vertically. Thus, the change in the values of both variables, i.e., the color of the light and the amount of fine mist generated per unit of time, is formulated into the “volcanic eruption” Method, that encapsulate the instructions of change of values of the first (color) variable controlled by a first actuator LED light, and the second (nebulizer) variables controlled by a second actuator nebulizer, all embedded in block 322. A “volcanic eruption” Method card 332 is then created that allows a programming user to change both the color of the LED light controlled by an actuator LED light, and the amount of fine mist generated by a nebulizer, with the actuators LED light and nebulizer all embedded within a single block 322.

In accordance with another embodiment of the present invention, a second actuator, i.e., a water nebulizer, may be embedded in another block 324. As a result, the change in the color of the light for the block 322 and the change in the amount of fine mist generated per unit of time for the block 324 are both formulated into the “volcanic eruption” Method. In executing the “volcanic eruption” Method, the interactive board 300 is configured to send, via wireless means, an instruction to both the block 322 and the block 324 respectively. Upon receiving the instructions, the LED light embedded in the block 322 changes colors and the water nebulizer embedded in the block 324 changes the amount of fine mist generated per unit of time to complete the execution of the Method “volcanic eruption” , as associated with the Method card 332. In this particular embodiment, more than one blocks are involved in the Method, and a single Object can be created to represent these blocks. To be specific, once the “volcanic eruption” Method card 332 is placed on the interactive board 300, another card 334 is also placed on the interactive board 300, with its UID read and associated with the two

blocks

322 and 324 referenced in the “volcanic eruption” Method, to create a new “volcano” Object card. With this process, the new Object volcano that does not exist before is thereafter created by a programming user. A programming user may further make a visual mark on the card 334 for ease of reference. Subsequently, as a user program is being developed, and upon the “volcano” Object card 334 being placed on the interactive board 300, the interactive board is configured to activate the user interface for changing the variables controlled by actuators in both block 322 and block 324.

In accordance with one embodiment of the present invention, the system further includes an audio element provided by a programming user. The interactive board 300 is configured to incorporate the audio element into a user programming element. The audio element can be in the form of a recording, and associated with a physical card. The incorporation of the audio element may be associating the audio element with a user programming card. Alternatively, the incorporation of the audio element may be associating the audio element with an audio card, and then placing the audio card together with a user-defined programming card. Alternatively, the incorporation of the audio element may be for a programming user to record the sound while performing the touch gesture.

In accordance with another embodiment of the present invention, a system for creating a user program is disclosed. The system includes multiple blocks, multiple Method cards, multiple system programming cards, and an interactive board. Each block is embedded with an actuator that controls a variable and no block is electrically connected with another block. Each Method card is associated with an instruction for a change in the value of a variable. And each system programming card is associated with a system programming element.

The process flow for the present invention has the following steps:

Step 401: creating a Method card, by associating the UID of a physical card with a Method that encapsulates an instruction for a change in the value of a variable controlled by an actuator embedded in a physical block, wherein, the said physical card is among a plurality of physical cards, each embedded with a UID, and the said physical block is among a plurality of physical blocks, each embedded with an actuator, and none of the physical blocks is electrically connected to another physical block;

Step 402: placing, by a programming user, multiple Method cards and system programming cards together, to form a programming structure, wherein, each system programming card is associated with a system programming element;

Step 403: reading, by a reader, the UIDs of the Method cards and system programming cards in the programming structure;

Step 404: transforming the programming structure into an executable user program;

Step 405: directing the execution of each of the Methods referenced in the user program, comprising implementing the said changes of values by each of the actuators and blocks referenced in the said Methods.

Each Method can be pre-determined, but can also be defined by a programming user, and the process of creating a Method card can be referred to Fig. 1 and descriptions therein.

The association of a Method with a Method card is typically done in one of following three ways:

1. through user interface and touch gestures by programming users, as detailed in Fig. 1 and Fig. 2; or

2. through a series of icons on a user interface; or

3. pre-set by manufacturers.

As shown in Fig. 5, the system includes an interactive board 500, multiple physical blocks 510, multiple Method cards 520, and multiple system programming cards 530.

Each physical block 510 is embedded with an actuator that controls a variable. Each block 510 also comprises a power source and a wireless communication means that allows the block to receive instructions from an external source. No member of the plurality of block 510 is electrically connected to another member of the plurality of block 510.

An example block simulating a traffic light, with three actuators that are LED lights. The variables each of the actuator LED light could control may include turning on, turning off, and changing color, brightness and duration of the light. A simplified version of a block simulating traffic light may include red, yellow and green LED lights as actuators, and the variables that each of the LED light controls may be the state of the light being either on or off.

Another example block may be a robotic car, and the variables it is able to control may include setting or changing direction, speed or extent of distance or rotational angle of the movement. Another example block is an audio speaker, and the variables it controls might be playing or stopping playing a sound.

In accordance with one embodiment of the present invention, the process of creating a Method card 520 is referred to Fig. 1 and descriptions therein. For example, a “red-light-on” card 522 associated with a Method encapsulating an instruction for a change (from off to on) in the value of a variable (state of light) controlled by an actuator (a red LED light) embedded in a block 510 (a block with three LED lights that mimic a traffic light) . In other words, the actuator is an LED light, the variable is the state of the light, and the “red-light-on” Method card 522 is associated with a value-changing instruction to turn on the red light. Similarly, the “car-stop” Method card 524 is associated with an instruction for stopping a robotic car.

In accordance with one embodiment of the present invention, the process of creating a Method card 520 has been accomplished by a manufacturer, before the system or method embodiment of the present invention becomes available for a programming user.

In accordance with one embodiment of the present invention, the process of creating a Method card 520 comprises placing a blank Method card 520 on an interactive board, and selecting from a menu of choices of Methods to associate with the unique ID of the said blank Method card 520, with the menu of choices of Methods provided by a manufacturer, rather than a programming user.

Each system programming card 530 is associated with a programming element. System programming elements are defined as: control, operator and comparators. A programming user is able to utilize these programming elements but is not able to alter the definition of these programming elements. Control comprises of but is not limited to: delay, loop, loop forever, loop until, if, then, else, exit program. Operator comprises of but is not limited to: add, subtract, multiply, divide, exponent, set, random integer, random float, square root, round, floor, ceiling, absolute, sign, minimum, maximum. Comparator comprises of but is not limited to: equal, not equal, less than, less than or equal, greater than, greater than or equal, and, or.

Once an programming user places multiple system programming cards 530, including an “IF” card 532 and a “THEN” card 534, and multiple Method cards 520, including the “red-light-on” Method card 522 and the “car-stop” Method card 524, on the interactive board 500 to form a programming structure 540, the interactive board 500 transforms the programming structure 540 into an executable user program and directs the execution of each of the Methods referenced in this user program, i.e., IF the red light within the traffic light block is on, THEN the motor within the robotic car block stops.

In another embodiment of the present invention, multiple user programs are created, and are integrated by a cloud server to form a single master user program. One example is an interactive battle game played by two programming users, who are referred to here as game players A and B, in which to players create a his or her own user program, and the two user programs are integrated by a cloud server. According to this embodiment of the present invention, players A and B each possesses attack cards that have various weapon and shield levels. Each attack card is a Method card that, when executed, produces light and sound effects, as well as damages to the opponent and reduction in shield to self. Each player may build a programming structure that outlines the sequence and conditions upon which each of the attack Method card is called for execution. The interactive board transforms the two programming structures into two user programs. A cloud server further integrates the two user programs into a master user program that directs the battle between the two players through their individual user programs of attack, and that helps the players to further sequence and debug their programmed actions.

In accordance with one embodiment of the present invention, the system further includes multiple identities to be assumed by a program user, with each identity associated with a set of rights and restrictions regarding an actuator or a specific block. Once an identity is assumed, the program user is informed of the rights and restrictions associated with the identity regarding the actuator or the block.

Such rights and restrictions may be explained in the embodiment of the battle game. Player A may define the weapon and shield levels, as well as light and sound effects, of Player A’s own attack Method cards and blocks. However, player A does not have the same rights over player B’s attack Method cards and blocks. In practice, such blocks could be figurines of a red army for player A and a blue army for player B. Furthermore, as Player A earns victory points, a processor is configured to allow Player A to be empowered with higher levels of weapons and shields. Same game rules apply to player B.

There are many ways that a programming user assumes an identity. In accordance with one embodiment of the present invention, an identity is a user account with login username and password. A programming user may place an identity card on the interactive board to indicate his or her identity. A programming user may also input information on the interactive board to indicate his or her identity. The interactive board may also capture biometric data of a programming user to determine his or her identity.

In accordance with one embodiment of the present invention, the execution of a Method may have a pre-condition, and such said pre-condition is not set by a programming user, but rather, the pre-condition is set by common sense, game rules, or laws of nature.

As shown in Fig. 6, and according to one embodiment of the present invention, a programming user may build a wind turbine that provides electricity to light up a building. Such an embodiment could be built with three blocks: a "wind simulator" block 611, with an embedded nebulizer to simulate wind blowing; a "wind turbine" block 612, with an embedded motor to simulate rotation of wind turbine and the resulting electricity generation; and a "building" block 613, with an embedded LED light.

A programming user may further create three Method cards, a "wind blowing" Method card that turns on the nebulizer within the wind simulator block 611 to produce fine mist for simulating the blowing of wind, a "power generation" Method that turns on the motor within the wind turbine block 612 for simulating the turning of the wind turbine and the generation of electricity, and a "light on" Method that turns on the lights within the building block 613.

If a programming user proceeds to build a user program, whereby the "power generation" Method is called for execution, the interactive board is configured to verify whether the pre-condition of the "power generation" Method has been met. Based on law of nature, such pre-condition is the blowing of wind. If the programming user has not called for the execution of the "wind blowing" Method by the wind simulator block 611 before calling for the execution of the "power generation" Method by the wind turbine block 612, then the pre-condition of the execution of the latter Method -"power generation" is not met, and the "power generation" Method is not executed by the "wind turbine" block 612. Likewise, the "power generation" Method is a pre-condition for the execution of the "light on" Method by the "building" block 613.

In accordance with one embodiment of the present invention, the execution of a first Method may trigger the execution of a second Method, whereby the execution of second Method is not set by a programming user, but rather, the first Method and the second Method have a causal relationship, as determined by common sense, game rules, or laws of nature,

An alternative embodiment may be described using the wind power example above -building a wind turbine that provides electricity to light up a building. As before, such an embodiment could be built with three blocks: a "wind simulator" block 611, with an embedded nebulizer to simulate wind blowing; a "wind turbine" block 612, with an embedded motor to simulate rotation of wind turbine and the resulting electricity generation; and a "building" block 613 with an embedded LED light.

After a programming user calls for the "wind blowing" Method to be executed by the wind simulator block 611, the interactive board is configured to call for the wind turbine block 612 to execute the power generation Method, simulating the process of wind power generation, and to call for the building block 613 to execute the light on Method, simulating the effect of such LED light having been powered by electricity from wind power generation. In this embodiment, the Methods of wind blowing and power generation have a causal relationship, and the Methods of power generation and light on have a causal relationship. Once the Method of wind blowing has been called for execution by a programming user, the subsequent Methods, power generation and light on, are executed as well with or without the input of an end-user (a programming user or an operating user) , since such cause-effect relationship simulates law of nature.

It should be obvious to those who are skilled in the art that a pre-condition need not be pre-defined by a programming user as a Method. Likewise, the action that an actuator executes as a consequence for a Method that has just been executed need not be pre-defined as a Method by a programming user either. The interactive board or a processor external to the blocks may formulate and execute these pre-conditions and consequential actions based on game rules, common sense, or law of nature, sometimes as a way to teach children causality or law of nature.

Embodiments described in Figs. 2-3 and Figs. 5-6 do not limit the scope of the present invention to any particular technology described therein. Additional embodiments are disclosed by Fig. 7 and Fig. 8 that aim to further describe the present invention in a way that is independent of the specific technological choices in the embodiments described in Figs. 2-3 and Figs. 5-6.

We shall now further clarify the technology terms utilized in Figs. 2-3 and Figs. 5-6. A UID of a physical card may be implemented with RFID tag according to one embodiment of the present invention. Alternatively, it may be implemented with optical identification (OID) technology, as OID code printed on the surface of the physical cards, according to another embodiment of the present invention. Such OID code can then be read by an OID reader, with such reading serves analogous purpose of an interactive board reading the RFID tag of a physical card. An OID reader may further read in sequence the UIDs of multiple cards placed together to form a programming structure, and send such programming structure to a computer for interpretation.

A UID of a physical card may be implemented with Optical Character Recognition (OCR) technology, according to one embodiment of the present invention. In this embodiment, characters printed or written or drawn by a user on the surface of a physical card can be read as regarded as the UID of the card.

In embodiments of the present invention where OID or OCR technologies are utilized to read the UIDs of a physical card, touch gestures are implemented with a programming user holding the OID or OCR readers in hand to scan a user interface whereby the readings of such scans are transmitted to a computer for analyzing the touch gesture and parameters of the touch gestures. The touch gestures implemented by the OID or OCR readers are therefore largely analogous to the touch gestures implemented by finger touches upon a touch screen with capacitive sensor arrays.

In accordance with one embodiment of the present invention, as shown in Fig. 7, the system includes a physical sheet 710 printed with OID code, multiple physical blocks 720, and multiple physical cards 730. Those who have ordinary skills in the art would recognize that OID codes are typically fine dots printed on a sheet and are typically invisible to the naked eye. However, in this embodiment of the present invention and for the sole purpose of simplified illustration, we have used small circles and squares to help visualize the differences in OID code. The physical sheet 710 is divided into several areas, with each area printed with OID codes representing different colors. For example, the OID code in area 712 represents red, 714 in green, 716 in yellow, etc. A block 722 among the multiple physical blocks 720 has three LED lights that mimic a traffic light. And each of the cards 730 is printed with an OID code as its UID.

A programming user interacts with the physical sheet 710 with touch gesture by an OID reader 750, such as an OID pen. The OID reader 750 is equipped with a wireless communication means, such as a Blue Tooth module, and is operatively linked to a computer which is not shown in Fig. 7 for simplicity. In particular, the programming user holds the OID reader 750 to long touch different areas of the physical sheet 710 to switch among several colors to formulate an instruction for a change in the color of the light. For example, if the area 712 is long touched by the OID reader 750, an instruction for turning on the red light embedded in the block 722 is formulated. The instruction is subsequently encapsulated into a “red-light-on” Method. Once the OID code printed on the surface of a card 732 among the multiple cards 730 is read by the OID reader 750, the UID of the card 732 is recognized and associated with the “red-light-on” Method to make the card 732 a “red-light-on” Method card. Method cards for turning on the light in other colors of the block 722 can be created in a similar manner.

OCR technology can also be utilized to create Method cards. In accordance with one embodiment of the present invention, the physical sheet 710 may be printed with different visual characters such as “red” , “green” , etc., and the touch gestures are implemented with programming users holding an OCR reader.

In accordance with one embodiment of the present invention, the creation of a user program is implemented with the OID technology. As seen in Fig. 8, multiple system programming cards 830, including an “IF” card 832 and a “THEN” card 834, and multiple Method cards 730, including the “red-light-on” Method card 732 and a “car-stop” Method card 734, are placed together to form a programming structure 840. OID codes are printed of the surface of all of these programming cards to serve as UIDs of the cards, and are again illustrated as small circles or squares in the figure. The system further comprises the physical blocks 720, including the “traffic light block” 722 and a robotic car block 724. A programming user may hold an OID reader 850 in hand to scan the surface of each of the programming cards in the programming structure 840 to read the UIDs of the cards. The programming structure 840 is then wirelessly transmitted to a computer (not shown in Fig. 8) . The computer transforms the programming structure into an executable user program, and directs each of the Methods referenced in this user program to be executed, i.e., IF the red light within the traffic light block 722 is on, THEN the motor within the robotic car block 724 stops.

Likewise, the creation of user programs could also be implemented with the OCR technology. One difference is that characters printed or written or drawn (e.g., “RED” on the surface of the “red-light-on” card) by a programming user on the surface of a programming card are read, by an OCR reader, and regarded as the UID of the card.

Claims

A method for creating a user-defined Method card, comprising:

performing, by a programming user, touch gesture upon a user interface to formulate a first instruction for a change in the value of a first variable;

wherein, the first variable is controlled by a first actuator embedded in a first physical block among a plurality of such physical blocks, with no physical block electrically connected with another physical block;

encapsulating the first instruction into a first Method;

reading, by a reader, the UID embedded in a first physical card, and associating the said UID with the first Method to create a first Method card;

selecting, subsequently and by the programming user, the first Method card; and

directing, via wireless communication means, the first actuator to execute the first Method, comprising implementing the said change in the value of the first variable.
The method of Claim 1, further comprising

performing, by a programming user, touch gesture upon a user interface to formulate a second instruction for changes in the values of the first variable and a second variable;

wherein, the second variable is controlled by the first actuator, or by a second actuator embedded in the first physical block, or by an actuator embedded in a second physical block;

encapsulating the second instruction into a second Method;

directing the execution of the second Method, comprising implementing the said changes in the values of the first variable and the second variable.
The method of Claim 2, further comprising:

associating the UID of a second physical card with the first physical block and the second physical block referenced in the second Method to create a first Object card.
The method of Claim 1, further comprising:

implementing, by the first actuator, the said change in the value of the first variable, while the said change is being formulated by the touch gesture, for the purpose of providing visual feedback to the programming user; and

performing, by the programming user, a modified touch gesture based on such visual feedback, in formulating the first instruction.
The method of Claim 1, further comprising:

capturing a parameter of the touch gesture; and

incorporating the parameter into the first instruction;

wherein, the touch gesture is selected from a group comprising touch gesture by finger or stylus on a capacitive sensor array, touch gesture by OID reader on a sheet printed with OID code, and touch gesture by OCR reader on a sheet printed or written or drawn with visual characters; and

wherein the said parameter is selected from a group comprising multiplicity of touch points, repetition of touches, intensity, duration, direction, speed and acceleration.
The method of Claim 1, further comprising:

providing an audio element by a programming user;

incorporating the audio element into the first Method.
A method for creating a user program, comprising:

creating a Method card, by associating the UID of a physical card with a Method that encapsulates an instruction for a change in the value of a variable controlled by an actuator embedded in a physical block;

wherein, the said physical card is among a plurality of physical cards, each embedded with a UID, and the said physical block is among a plurality of physical blocks, each embedded with an actuator, and none of the physical blocks is electrically connected to another physical block;

placing, by a programming user, multiple Method cards and system programming cards together, to form a programming structure;

wherein, each system programming card is associated with a system programming element;

reading, by a reader, the UIDs of the Method cards and system programming cards in the programming structure;

transforming the programming structure into an executable user program;

directing the execution of each of the Methods referenced in the user program, comprising implementing the said changes of values by each of the actuators and physical blocks referenced in the said Methods.
The method of Claim 7, further comprising:

integrating, by a cloud server, multiple user programs created by more than one programming user, or read by more than one reader, to create a master user program, for purposes that comprise debugging and sequencing said instructions.
The method of Claim 7, further comprising:

associating rights and restrictions regarding an actuator or a physical block with an identity among a plurality of end-user identities;

assuming an identity by a programming user; and

implementing, and informing the programming user of, rights and restrictions associated with the said identity regarding the said actuator or said physical block.
The method of Claim 7, further comprising:

verifying a pre-condition for a Method before executing the said Method;

directing the execution of a subsequent Method after executing the said Method;

wherein, the said Method and the subsequent Method have a causal relationship.
A system for creating a user-defined Method card, comprising:

a plurality of physical blocks, each physical block embedded with an actuator that controls a variable and no physical block electrically connected with another physical block;

a user interface;

a plurality of physical cards, each embedded with a UID;

a reader that reads the UID of a physical card, upon the physical card being brought to proximity to the reader;

a computer;

a wireless communication means between the computer and a physical block;

wherein, a programming user performs touch gesture upon the user interface to formulate a first instruction for a change in the value of a first variable; and

wherein, the computer is configured to encapsulate the first instruction into a first Method, and associate the first Method with the UID of the first physical card to create a first Method card; and

wherein, subsequently, a programming user selects the first Method card; and

wherein, the computer is configured to direct the first actuator to execute the first Method, comprising implementing the said change in the value of the first variable.
The system of Claim 11,

wherein, a programming user performs touch gesture upon the user interface to formulate a second instruction for changes in the value of the first variable and a second variable; and

wherein, the second variable is controlled by the first actuator, or by a second actuator embedded in the first physical block, or by an actuator embedded in a second physical block; and

wherein, the computer is configured to encapsulate the second instruction into a second Method, and direct the execution of the second Method comprising implementing the said changes in the value of the first variable and the second variable.
The system of Claim 12,

wherein, the computer is configured to create a first Object card, by associating the UID of a second physical card with the first physical block and the second physical block referenced in the second Method.
The system of Claim 11,

wherein, the computer is configured to direct the first actuator to implement the said change in the value of the first variable, while the said change is being formulated by the touch gesture, for the purpose of providing visual feedback to the programming user; and

wherein, the programming user performs a modified touch gesture based on such visual feedback in formulating the first instruction.
The system of Claim 11,

wherein, the touch gesture is selected from a group comprising touch gesture by finger or stylus on a capacitive sensor array, touch gesture by OID reader on a sheet printed with OID code, and touch gesture by OCR reader on a sheet printed or written or drawn with visual characters; and

wherein the reader is configured to capture a parameter of the touch gesture, and incorporate the parameter into the first instruction; and

wherein the said parameter is selected from a group comprising multiplicity of touch points, repetition of touches, intensity, duration, direction, speed and acceleration.
The system of Claim 11, further comprising an audio element provided by a programming user, wherein, the computer is configured to incorporate the audio element into the first Method.
A system for creating a user program, comprising:

a plurality of physical blocks, each embedded with an actuator that controls a variable and no physical block electrically connected with another physical block;

a plurality of physical cards, each embedded with a UID;

a plurality of system programming physical cards, each embedded with a UID and associated with a system programming element;

a reader that reads the UID of a physical card, upon the physical card being brought to proximity to the reader;

a computer;

wherein, a programming user creates a Method card, by associating the UID of a physical card with a Method that encapsulates an instruction for a change in the value of a variable controlled by an actuator embedded in a physical block; and

wherein, a programming user further places multiple Method cards and system programming cards together, to form a programming structure; and

wherein, the reader reads the UIDs of the Method cards and system programming cards in the programming structure, and the computer is configured to transform the programming structure into an executable user program, and direct the execution of the user program, comprising implementing said changes of values by each of the actuators and physical blocks referenced in the said Methods.
The system of Claim 17, further comprising a cloud server,

wherein, the cloud server is configured to integrate multiple user programs, created by more than one programming user, or read by more than one reader, to create a master user program, for purposes that comprise debugging and sequencing said instructions.
The system of Claim 17, further comprising a plurality of end-user identities, each associated with rights and restrictions regarding an actuator or a physical block,

wherein, upon a programming user assuming an identity, the interactive surface is configured to implement, and inform the programming user of, rights and restrictions associated with the said identity regarding the said actuator or said physical block.
The system of Claim 17,

wherein, before directing the execution of a Method, the computer is configured to verify a pre-condition for the said Method; and

wherein, after the execution of the said Method, the computer is configured to direct the execution of a subsequent Method that has a causal relationship with the said Method.