WO2010093995A1 - Apparatuses, methods and systems for an interworld feedback platform bridge - Google Patents

Apparatuses, methods and systems for an interworld feedback platform bridge Download PDF

Info

Publication number
WO2010093995A1
WO2010093995A1 PCT/US2010/024196 US2010024196W WO2010093995A1 WO 2010093995 A1 WO2010093995 A1 WO 2010093995A1 US 2010024196 W US2010024196 W US 2010024196W WO 2010093995 A1 WO2010093995 A1 WO 2010093995A1
Authority
WO
WIPO (PCT)
Prior art keywords
toy
data
world
real
computer generated
Prior art date
Application number
PCT/US2010/024196
Other languages
French (fr)
Inventor
Shervin Pishevar
Original Assignee
Social Gaming Network
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/US2010/023961 external-priority patent/WO2010093831A1/en
Application filed by Social Gaming Network filed Critical Social Gaming Network
Publication of WO2010093995A1 publication Critical patent/WO2010093995A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the present invention is directed generally to an apparatuses, methods, and systems of enhancing user interaction and communication across different environments, and more particularly, to APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE.
  • Social networks allow users to identify and communicate with each other via home computers, either socially (e.g., Facebook, MySpace) or professionally (e.g., Linkedl ⁇ ).
  • Computer-based simulations allow users to inhabit and interact in simulated digital environments. Simulated environments may be three-dimensional and may include simulated or generated characters that represent users. Some simulated environments may function as games (e.g., World of Warcrqft), while others are more like the real world (e.g., Second Life). Users access and interact with these simulated environments via home computers and video game consoles. Some toys, such as Webkinz, provide a unique identifier along with the purchase of a static physical toy, that acts as a password to allow users to access a simulated environment..
  • IFP BRIDGE facilitates interactions and communications, between devices in the real world (“real-world”), and in some embodiments, between the real-world and one or more social networks and/or other computer generated environments (“virtual-worlds”) (e.g., virtual realities/ worlds).
  • the IFP BRIDGE may associate a first real-world toy-device with a second real-world toy-device, and coordinate interactions between the toy-devices.
  • the interactions may be triggered by some external signal, such as a received instruction or environmental cue.
  • the IFP BRIDGE coordinates interactions between a real-world toy-device and a social network component and/or corresponding toy-avatar in one or more virtual-worlds. Subsequent user interactions with the real-world toy-device are monitored and may influence aspects of a profile in a social network and or a toy-avatar in a virtual-world. Similarly, in certain implementations, the IFP BRIDGE monitors the action/interactions in a social network and/or of a toy-avatar in the virtual-world and determines and executes appropriate response actions for the toy-device in the real -world.
  • FIGURE 1 is an overview diagram illustrating an implementation of an embodiment of the APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE (hereinafter "IFP BRIDGE");
  • FIGURE 2 discloses aspects of component implementation for an embodiment of the IFP BRIDGE;
  • FIGURE 3 is a logic flow diagram illustrating aspects of an embodiment of the IFP BRIDGE;
  • FIGURE 4A-B are logic flow diagrams illustrating aspects of real-world toy-device registration within an embodiment of the IFP BRIDGE;
  • FIGURE 5A-B provide logic flow diagrams illustrating aspects of real- world-virtual-world interactions within an embodiment of the IFP BRIDGE;
  • FIGURE 6A-B are logic flow diagrams illustrating aspects of an alternative embodiment of the IFP BRIDGE
  • FIGURES 7A-C provide example screen shots illustrating aspects of different implementations of IFP BRIDGE
  • FIGURES 8A-B provide example specification details on toy-devices and virtual-worlds within one embodiment of IFP BRIDGE;
  • FIGURE 9 provides an overview diagram illustrating an IFP BRIDGE real- world toy-device with replaceable electronic components in one embodiment of IFP BRIDGE;
  • FIGURES 10A-J provide example circuit diagrams illustrating implementations of an IFP BRDIGE toy-device controller in one embodiment of IFP BRIDGE.
  • FIGURE 11 is of a block diagram illustrating embodiments of the IFP BRIDGE controller.
  • IFP BRIDGE [O O 2O] This disclosure details aspects of APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE (hereinafter, "IFP BRIDGE").
  • IFP BRIDGE may serve to facilitate and coordinate interactions and communications between multiple devices in the real world ("real- world").
  • the IFP BRIDGE may facilitate and coordinate interactions and communications between one or more device in the real-world and one or more social networks and/or computer generated environments (“virtual- worlds").
  • an IFP BRIDGE real -wo rid toy-device may take a similar look with a stuffed toy (e.g., a bear, a rabbit, etc.) but having a processor in controlling various built-in electronics, such as animatronics (e.g., movable eyes, mouth, cheeks, etc.), speaker/microphones, wireless receivers, LCD display, sensors, accelerometers, and/or the like.
  • animatronics e.g., movable eyes, mouth, cheeks, etc.
  • wireless receivers e.g., LCD display, sensors, accelerometers, and/or the like.
  • the real-world toy-device may register with an application in the IFP BRIDGE virtual-worlds via wireless connections to associate with a corresponding toy-avatar, e.g., a video game, a virtual community, etc., and exchange data with the virtual -worlds to synchronize the status of the real-world toy-device and the virtual-world toy-avatar.
  • a corresponding toy-avatar e.g., a video game, a virtual community, etc.
  • the real-world toy-device may show a smile by controlling mouth movement through its animatronics, and send electronic data describing its 1 current status, e.g., "Hugged: Happy,” to the virtual-worlds.
  • the real-world toy-device may show a smile by controlling mouth movement through its animatronics, and send electronic data describing its 1 current status, e.g., "Hugged: Happy," to the virtual-worlds.
  • 1 current status e.g., "Hugged: Happy
  • the virtual-worlds may update the status associated with the profile of the toy-avatar
  • 5 may show an updated status as "Hugged: Happy” and in turn send the status updates
  • the real-world toy-device may
  • FIGURE 1 is of a block diagram illustrating an overview of an
  • network server 127 a blog/microblog server 126, an IFP BRIDGE database 119, and a
  • 16 101a is registered with the IFP BRIDGE via a user device 115.
  • the user For example, the user
  • 17 device 115 may include a wide variety of different devices and technologies such as, but
  • a real-world toy-device 101a is automatically
  • 21 device may connect to a home computer 115 via a local area network 105a, such as
  • the IFP BRIDGE may register a real-world toy-device by identifying information such as, but not limited to physical address (e.g., MAC address), IP address, hardware identification, network acronym, and/or the like.
  • identifying information such as, but not limited to physical address (e.g., MAC address), IP address, hardware identification, network acronym, and/or the like.
  • a user may activate, configure, and register the toy-device ioia, for example, via a user device 115.
  • a registration interface may have fields (e.g., lisa-use) that allow a user to enter a name for the toy-device, an email address, an owner name, password, associated virtual- world account(s) (e.g., Facebook, MySpace, SecondLife, Twitter, etc.) and/or the like, that is stored and registered at the IFP BRIDGE server 120.
  • a password may be used to make a digital certificate encrypted key (and/or the like) for providing enhanced security between the toy-device and the server.
  • the interface may also allow a user to upload a picture or pictures (for example, for use in subsequent face recognition by the toy-device).
  • IFP BRIDGE may allow a user to access the online profile of the real-world toy-device 101a and configure the toy-avatar in the virtual-worldi32/i25-i28.
  • the IFP BRIDGE may provide the user with a view of their toy-avatar 102a (e.g., via a virtual-world interface on the user's laptop or home computer 116), status (e.g., via a social network or blog/microblog update interface 117a on the user's laptop, home computer, cell phone, PDA, etc.), and/or the like, and may provide similar views/information to other users of the virtual-worlds.
  • a corresponding account may be created and/or linked to in a social network running on one or more servers
  • a corresponding toy-avatar may be created or activated in a virtual-world running on one or more 1 servers
  • the real -world toy-device ioia may be linked to a second real -world
  • virtual-worlds 3 crowdsourcing site, virtual-world, and/or the like (hereinafter “virtual-worlds") 132
  • IFP BRIDGE servers 120 5 IFP BRIDGE servers 120, while in other embodiments virtual-worlds may be
  • 11 made available 136 including, but not limited to, subscription or pay services or
  • the IFP BRIDGE utilizes real-world toy-devices that
  • a user stimulating the sensors e.g., a user stimulating the sensors (e.g.,
  • the toy-device may contain integrated components that provide
  • the communications network 110 to one or more servers 120.
  • the communications network is 20 communications network 110 to one or more servers 120.
  • 21 110 may, for example, comprise a mobile data network, local area network, the internet,
  • instructions may be issued to the social network
  • instruction may be issued causing to
  • the IFP BRIDGE monitors the
  • the IFP BRIDGE may transmit instructions to toy-device that cause the eyes
  • the IFP BRIDGE entities such as the user devices 115-
  • 21 servers 125-128, and/or the like may also communicate with an IFP BRIDGE database
  • distributed IFP BRIDGE databases may be integrated in-
  • the IFP BRIDGE entities may access a remote IFP BRIDGE database 119 via the communication network 110.
  • the IFP BRIDGE entities may send data to the database 119 for storage, such as, but not limited to user account information, toy profile information, hardware information, application data, protocol data, application history, and/or the like.
  • the IFP BRIDGE database 119 may be one or more online database connected to a variety of vendors, such as hardware vendors (e.g. Apple Inc. , Intel, Sony, etc.), application vendors (e.g.
  • ToyBots Nintendo, Game Cube, Game Boy, etc.
  • virtual world service vendors e.g. ActiveWorlds, Second Life, etc.
  • social media vendors e.g., SGN, Twitter, Facebook, MySpace, etc.
  • the real-world toy-devices ioia-b, user devices 115-117, the IFP BRIDGE server 130 and/ or the virtual-worlds servers 125-128 may constantly, intermittently, and/or periodically download updates, such as updated user profile, updated software programs, updated command instructions, and/or the like, from the IFP BRIDGE database 119 via a variety of connection protocols, such as Telnet FTP, HTTP transfer, P2P transmission and/or the like.
  • a system administrator may communicate with the IFP BRIDGE entities for regular maintenance, service failure, system updates, database renewal, security surveillance and/ or the like via the communication network 110.
  • the system administrator may be a user, who may directly operate with home computers 115-117 to configure system settings, parental control, and/or the like.
  • the system administrator may be an IFP BRIDGE administrator operating with the IFP BRIDGE server 120 to monitor the IFP BRIDGE system.
  • FIGURE 2 shows an implementation of IFP BRIDGE system components for the toy-device in one embodiment of IFP BRIDGE operation.
  • the toy-device 201 may contain a number of functional modules and/ or data stores.
  • a toy-device IFP BRIDGE controller 205 may serve a central role in some embodiments of IFP BRIDGE operation, serving to orchestrate the reception, generation, and distribution of data and/or instructions to, from and between IFP BRIDGE modules and/or mediate communications with external entities, systems, servers, and/or environments.
  • the IFP BRIDGE controller 205 may be housed separately from other modules and/or databases within the IFP BRIDGE system, while in another embodiment, some or all of the other modules and/or databases may be housed within and/or configured as part of the IFP BRIDGE controller. Further detail regarding implementations of IFP BRIDGE controller operations, modules, and databases is provided below.
  • the toy-device IFP BRIDGE Controller may be coupled to one or more interaction components and/or functional modules (sensors, interaction interfaces, and/or the like).
  • the toy-device IFP BRIDGE may be coupled to an audio I/O (input/ output) 225a, video I/O 225b, location sensor(s) 225c (e.g., GPS, location triangulation, etc.), touch sensor(s) 225d, movement sensor(s) 225e (e.g., accelerometer), interaction I/O 225f (animatronics, interfaces, responsive servos, and/or the like), and/or other sensor I/O 225g.
  • a further user interface may be provided and configured to receive user inputs and display 1 application states and/or other outputs. The UI may, for example, allow a user to adjust
  • the user interface 210 the user interface 210
  • 5 may include, but not limited to devices such as, keyboard(s), mouse, stylus(es), touch
  • a UI may be
  • the toy-device IFP BRIDGE Controller may
  • the applications engine 215 may receive sensory input information
  • the updated application state data may be transferred a user device (a home computer),
  • 15 engine may comprise an "Electronic Pet” gaming platform, which may provide “petting”
  • 17 Pet such as “Hungry,” “Sick,” etc.
  • a user I/O interface e.g., the video I/O
  • the toy-device IFP BRIDGE 19 [o 037] As discussed above, in some implementations, the toy-device IFP BRIDGE
  • Controller 205 may be coupled to an interaction module 220, configured to interface
  • the interaction/sensor I/O components 225a-225g may be stimulated by
  • interaction/sensor I/O components 225a-225g such as but
  • transducers not limited to transducers, accelerometers, thermometers, anemometers, barometers,
  • interaction/sensor module 220 configures signals received from the interaction/sensor
  • the toy-device IFP BRIDGE Controller 205 may
  • communications I/O components 235 may comprise components facilitating
  • Communication I/O components 240 may, for example, contain ports, slots,
  • Communication protocols and/or formats for which the communications module 230 and/or communications I/O components 235 may be compatible may include, but are not limited to, GSM, GPRS, 3G EDGE, W-CDMA, CDMA, CDMA2000, HSDPA, Ethernet, WiFi, Bluetooth, USB, and/or the like.
  • the communication I/O 235 may, for example, serve to configure data into application, transport, network, media access control, and/or physical layer formats in accordance with a network transmission protocol, such as, but not limited to FTP, TCP/IP, SMTP, Short Message Peer-to-Peer (SMPP) and/or the like.
  • the communications module 230 and communications I/O 235 may further be configurable to implement and/or translate Wireless Application Protocol (WAP), VoIP and/or the like data formats and/or protocols.
  • the communications I/O 235 may further house one or more ports, jacks, antennas, and/or the like to facilitate wired and/or wireless communications with and/or within the IFP BRIDGE system.
  • the IFP BRIDGE controller 205 may transmit the received sensor data characteristics of the motion of the toy-device, which may be interpreted as "Hug,” “Feed,” etc., to the communication module 230, and the data may then be transmitted to external entities (e.g. the IFP BRIDGE server, etc.) through the communications I/O 235.
  • the communications module 230 may comprise web server software, e.g., Apache, equipped to configure application state data for publication on the World Wide Web.
  • Published application state data may, in one implementation, be represented as an integrated video, animation, rich internet 1 application, virtual-world data, and/or the like, and may be configured in accordance
  • the toy-device IFP BRIDGE controller 205 may
  • An applications database 240 may contain application data
  • a protocols database 245 may contain
  • 11 246 may contain data pertaining to toy-device hardware data, toy-device account data in
  • the IFP BRIDGE controller may be further
  • CPEs Premise Equipments
  • a hardware database may contain information
  • database may specify transmission protocols, data formats, and/or the like suitable for
  • the IFP BRIDGE databases may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like.
  • the XML for a Toy Profile in the toys database 246 may take a form similar to the following example:
  • Figure 3 provides an overview of logic flow illustrating aspects of implementing the IFP BRIDGE with a real-world toy-device and virtual-worlds in one embodiment of the IFP BRIDGE operation.
  • a user may initialize a real-world toy-device, e.g., through toy configuration and turning on the power, etc., and register the real-world toy-device with the IFP BRIDGE 305, as will be illustrated in Figures 4A-B.
  • the IFP BRIDGE virtual -worlds may instantiate an IFP BRIDGE application 310.
  • an IFP BRIDGE enabled application component e.g., a video game, etc.
  • a plug-in of an IFP BRIDGE component may be used to establish the computer to a virtual-world for second life.
  • the IFP BRIDGE may also connect to its own virtual world source, e.g., WooZee's or ToyBot virtual world.
  • an IFP BRIDGE component may be initialized and connected to social media, such as facebook, twitter, MySpace, flickr, and/or the like.
  • the IFP BRIDGE may monitor any actions and/or status updates of both the real-world toy-device, and the virtual-worlds 315, and instantiate the real-world-virtual-worlds interactions to synchronize status of the real- world toy-device and a corresponding virtual-world toy-avatar 320, as illustrated in Figures 5A-B.
  • the IFP BRIDGE may monitor any environment stimuli, e.g., stimuli from another real-world toy-device, environment, 325, and instantiate interactions between two real-world toy-toy interactions, and/or communications between two virtual-world toy-avatars 330, as illustrated in Figures 6A-B.
  • Figures 4A-B provide logic flow diagrams illustrating aspects of registering a real-world toy-device with the IFP BRIDGE in one embodiment of the IFP BRIDGE operation.
  • the real-world toy-device registration may be automatically completed by the toy-device.
  • an IFP BRIDGE real-world toy-device 401 may be instantiated (e.g., powered on) 405, it may automatically query and connect with a virtual-world device 406.
  • the real-world toy-device may query for a computing device 402, such as, but not limited to a laptop, a desktop, a PDA, a smartphone, and/or the like, within a local area network via zero-configuration protocols.
  • the zero-configuration protocols may be any of Service Location Protocol (SLP), Universal Plug and Play (UPnP; e.g., via 1 USB), Jini, Bluetooth Service Discovery Protocol, WS-Discovery, Proprietary Discovery
  • 3 device may directly connect to a virtual-world server via Wi-Fi, 3G networks, and the
  • 4 virtual-world server may receive an indication of registration request 410 from the real-
  • the IFP BRIDGE may prompt the user computing
  • the user computing device the user computing device (computer) 402 may receive a
  • the IFP BRIDGE may generate a toy-
  • IFP BRIDGE 14 avatar by an IFP BRIDGE enabled application component 416.
  • the IFP the IFP
  • BRIDGE may query a database based on the received identifying data of the real-world
  • identification of the real-world toy-device may indicate the toy is a "bear.”
  • the IFP BRIDGE allows a user to select an avatar for the
  • VNC 21 may establish a secure communications path and synchronize data 419.
  • information such as profile information, initial device status,
  • the virtual-world and the real-world toy-device may update an action definition list
  • the virtual-world may
  • 9 servers may update user accounts with the newly generated real-world toy registration
  • the IFP BRIDGE may query a user database
  • the IFP BRIDGE may generate a new user account for the
  • the IFP BRIDGE 14 newly registered real-world toy-device.
  • the IFP BRIDGE 14 newly registered real-world toy-device.
  • 15 may publish a message indicating the new toy via social media, crowd sourcing sites,
  • Figure 4B illustrates an alternative implementation of real-world toy-
  • a user may submit a registration request 430
  • a user operating a user computer 402 may access an
  • the user may enter information with regard to the real-world toy-
  • 22 device 435 including user name, account name, toy-device hardware information, and
  • the virtual-world may generate a registration entry 440 based on the user submitted information, e.g., via web form to an information server/database.
  • the virtual-world may send registration information to virtual-worlds servers 445 and update user account with the real -world toy registration 450 in a similar manner as discussed in Figure 4A.
  • the real-world toy-device may, or may not participate in the registration described in 430-450.
  • the IFP BRIDGE allows a user to register a real-world toy-device when the device is powered off or not available.
  • FIGURE 5A provides a logic flow diagram illustrating aspects of the real- world toy-device and the virtual -world interaction in one embodiment of the IFP BRIDGE operation.
  • the IFP BRIDGE real-world toy-device may monitor status updates 500.
  • a toy-device may have a number of interaction/sensors (225a-225g), which may be monitored by the toy-device IFP BRIDGE controller.
  • the real-world toy-device may determine whether it senses any touch 502 (e.g., via sensors, etc.), motion 504 (e.g., via an accelerometer, etc.), location change 505 (e.g., via a GPS receiver, etc.), environment stimuli 506 (e.g., via a thermometer, wireless receivers, etc., as will be further illustrated in Figures 6A-B), and/or the like. If any of 502-506 takes place, the real-world toy-device may generate action data based on the sensor updates 510.
  • the generated action data may be compliant with a pre-determined data format.
  • the 1 generated action data may take a form similar to a binary data packet including fields, as
  • the data payload may take a form similar to, a 64-byte
  • action type field including an indication of the sensed action
  • action intensity value e.g., pressure intensity, light intensity, sound
  • the real-world toy-device may form a query based
  • the action definition entry of receiving a hug may further indicate
  • the action definition entry of receiving a hug may further
  • an action-response list may be similar to: Action Response
  • An example XML for an example action-response entry may take a form similar to the following example:
  • a query on the action definition list may not return any result - e.g., the pressure intensity indicated in the generated data may not match with the definition of a "Hug" in the action definition list.
  • the real-world toy-device may proceed with monitor the real-world toy status updates 500.
  • the real-world toy-device may receive a synchronization request 508 from the virtual-worlds.
  • the real-world toy-device may receive and determine the type of the synchronization data 522.
  • the virtual-worlds may synchronize updated action definition list(s) 524 with the real- world toy-device 530.
  • the virtual-worlds may receive an updated action definition list via software upgrade, user submission, and/or the like, and may send the updated action definition list to a real-world toy-device.
  • the toy-device may run a microserver and send an HTTP(S) post command request for updated behaviors with its device ID.
  • the server will query its driver database based on the device type identification and may similarly send back an updated driver via HTTP(S) post. [O O 6 O ]
  • the received synchronization data is a segment of new action data (e.g., in the binary data packet format discussed above)
  • the real- world toy-device may proceed with 512.
  • the real-world toy-device may proceed with 516 to execute responsive actions as discussed above.
  • the virtual-world status update data may be originated by a virtual-world toy-avatar status update, a message published in the social media, crowd sourcing site, blog/microblog, and/or the like.
  • Figure 5B provides a logic flow diagram illustrating aspects of interactions between virtual-worlds and a real-world toy-device in an alternative embodiment of the IFP BRIDGE operation.
  • a user may register and/or configure accounts associated with one or more social networking sites, blogs/microblogs, crowdsourcing applications, and/or other virtual-worlds (e.g., a toy- avatar that corresponds to a particular toy-device).
  • a specified account and/or profile e.g., toy-avatar profile
  • one or more users may interact with the social networking toy-account, toy-blog/microblog, toy-feed, and/or virtual-world-associated element (toy-avatar).
  • a user may access a social networking site or microblog feed and interact with the toy- account, toy- profile, and/or toy-feed associated with his or her toy-device.
  • twittering "Hug Woozee" to a twitter account associated with the toy-device may get a response from the toy's server virtual avatar after receiving the twitter hug, or may be routed directly to the toy, either of which may parse the action and send back a response 'WooZee miss you," "Woozee hug you too,” and/ or the like.
  • a user may access a virtual-world and interact with a toy-avatar that is associated with a toy-device they have purchased.
  • other users may interact with the toy-accounts, toy-feeds, toy-avatars, and/or the like.
  • individual toy-avatars may interact with each other. 1
  • the virtual-worlds may
  • the virtual-world may receive
  • 7 virtual-worlds may update the toy/user profile 560 based on the received data if any of
  • the virtual-worlds may update toy/user profile
  • the virtual-world may query a action definition list 561/562, and execute
  • the virtual-worlds may search for the real-world toy-device on a
  • the virtual-worlds may send instructions of status updates and
  • the virtual-world may notify a user of new action type 563. For example,
  • a user may submit desired action in a descriptive script, such as "Pat,” etc., whereby the action "Pat” may not be defined in the action definition list.
  • the IFP BRIDGE virtual-world may provide a user interface for the user to define the action "Pat” and add it to the action definition list.
  • a user may submit a request to add a new action to the virtual-world server.
  • the communications between the real-world toy-device and the virtual- world may be supported by a method-call semantics mechnism, e.g., CORBA.
  • CORBA semantics mechnism
  • the real-world toy-device may run a kernel linux platform (e.g., BusyBox, etc.) to interface an object request borker of a CORBA infrastructure as shown in Figure 5C, and thus invoke a remote object on the virtual- worlds running on a user computer, e.g., each toy-device/toy-avatar is defined as an object.
  • a kernel linux platform e.g., BusyBox, etc.
  • each toy-device/toy-avatar is defined as an object.
  • such CORBA mechanism may be used based on various development tools and libraries, e.g., GCC, iPhone SDK, and/or the like.
  • the toy-device and the virtual world may define a series of objects, such as, but not limited to accelerometer which may contain information regarding accelerometer status, GPS which may contain information about the device location, pointer which contains information about the user interaction on the screen, screen which contains the screen stream, and/or other data structure which may contain various data streams and constructs pertaining to a given application.
  • the toy-device 5022 as a host may interface with object structure 5025, object Class Structure 5027 running on an object requested broker 5029, and communicate with virtual world 5055 via a network connection 5030.
  • the virtual world may implement a specified object 5050, object skeleton code 5037 running on the target 1 device side object requested broker 5035.
  • FIGURE 6A-B provide illustrative logic flow diagrams for an embodiment
  • the toy-device sensors monitor for stimuli 6002.
  • the relevant stimuli may be general categories of stimuli (e.g.,
  • 11 actions are indicated 6006. Depending on the embodiment, this determination may be
  • the toy-device may have one or more sensors
  • remote server may cause the toy device to react, for example: dance, act out a scene,
  • This type of response may also be derived via the action definition list, but
  • an interpreted input may be utilized, e.g., if a
  • timing supports to activate motors/peripherals.
  • the toy-device may control an arm motor to wave up and down within 30
  • the environmental stimuli monitoring may include
  • FIGURE 6B provides an illustrative
  • the toy-device monitors for the presence of other toy-device
  • 11 devices 602 for example, using Bluetooth, wifi, infrared, and/or the like. If another toy-
  • a communication application may be engaged/activated 608 to
  • the toy-device may request an ID (and/or like indicia, security tokens, etc.) from
  • the verification can be confirmation that
  • 17 toy-device ID is from a toy-device in a "trusted” or “approved” list.
  • trusted toy-devices may be identified based on social network
  • a user may be prompted to specify whether a certain toy-
  • 23 toy-device may be excluded from monitoring 620 (e.g., further communication is disabled). If it is determined that the toy-device is trusted 618, communication and interaction is enabled, and the toy-devices can communicate and interact 622. If a communication is received from a trusted toy-device 624, and an action is indicated 626, the action is then executed 628 (as discussed in detail above). In some embodiments, different levels of trust or access may be specified, and as such, may limit or otherwise specify permitted/ disallowed actions/instructions. In some implementations, the presence/monitoring for other toy-devices may be tunable/ sharable, such that parameters govern the identification and interaction between toy-devices.
  • the communication/coordination between toy-devices may allow two or more toy-devices to act out a movie scene (and particular, when combined with the features discussed in FIGURE 5, act out a movie scene when the scene is playing on a television or the like), have a dialogue, coordinate dance moves, etc.
  • a toy-device may be identified by another toy-device as authorized, and recognize its device type. The other toy-device may then send an action either directly or via virtual-world bridge to the first toy-device, and then the other toy-device may interpret and react to the received action.
  • real-world toy-device applications may be written as widgets, for example, in JavaScript and executed by the toy-device's on-board web server.
  • an online store allows for the aggregation and selling of various real-world toy widget applications that may be purchased and then downloaded to a user's real-world toy-device associated with their profile/account.
  • these widget can make use of underlying applications called Behaviors. Behaviors may themselves be applications that drive underlying real-world toy-device sensors and/or actuators. For example, a behavior may be to blink, where a toy-device's servos are actuated to move toy eyes opened and closed.
  • applications may build upon abstracted behaviors to various real-world toy-device implementations.
  • applications may make use of real-world on-board sensors to generate contextualized behavior. For example, when the real-world toy-device has a camera to detect proximity of strangers in addition to the real-world toy-device's handler, a GPS sensor will inform the toy to say “Bonjour” when in France, and "HoIa” when in Spain.
  • Figures 7A-C provide example screen shots illustrating aspects of different implementations of the IFP BRIDGE operation.
  • the ICFP BRIDGE may make applications/services available for implementation on a toy-device, toy- account/profile, and/or toy-avatar. Some of these applications/services utilize records and/or profiles associated with toy-devices.
  • a toy- device may implement a to "story-time" application that allows a user on a social networking site or in a virtual-world to talk to or provide an audio file to a toy-avatar.
  • This interaction may be stored (e.g., a recording of what was said by the user is made and stored in a database, or the audio file is similarly stored) and may be subsequently transmitted to and stored by the toy-device via data synchronization 707 between the real-world toy-device and the virtual-worlds.
  • a user of the toy- device may be able to activate playback of the recording at any time after the toy-device has received and stored it 701.
  • the playback may be activated by a user touching and/or hugging the real-world toy-device 705, and/ or articulate "Tell Story" as the real-world toy-device may analyze the user speech and translate into a command to playback the story. 1 [o o 74]
  • a user may configure the story playback
  • a user's friends/family may record a
  • the real-world toy-device may receive and perform such
  • the toy-device may control a
  • the toy-device may be a display output of the toy
  • the toy device may be monitored and/or recorded. As shown in Figure 7B, for example,
  • a user of a social media may send an audio message to the toy-account of another user
  • the social networking site e.g., a grandmother sends a message to her
  • the toy-device may subsequently play the audio message, and record the toy
  • This recorded/monitored response may then be saved locally, transmitted to
  • these messages may be staged, stared and redirected from the virtual-world server.
  • the toy may be interacted with and the virtual-world toy avatar may reflect and respond to actions on the toy. For example, hugging the toy- device would cause a virtual-world avatar an action of hugging.
  • the virtual-world may be displayed right on the toy-device's LCD screen.
  • the toy may be used as a game controller to cause movement of a virtual-world avatar, as further illustrated in Figure 7C.
  • accessing an application such as a story-time application, may require that there be one or more changes or events, as indicated by the internal record.
  • activating the toy-device playback element of the story-time application may require that the toy-device internal record indicate that the toy-device has been hugged at least twice within the last hour, that the toy-device is in a designated location (e.g., the home of the owner/user, as indicated by a GPS or like component), that the toy-device is currently being held (as indicated by a touch sensor), and that the local time is after 7 pm. If all of these conditions are met, the toy-device then plays the most recent recording stored by the story-time application. Playback may include audio playback as well as animatronics and/or other features of the toy-device.
  • Other applications may include coordinated movements (e.g., dancing, fighting, etc.) between two or more toy-devices, as discussed in greater detail regarding Figures 7A-B.
  • coordinated movements e.g., dancing, fighting, etc.
  • Such interactions may require that additional preconditions be met before being carried out, for example, that the toy devices are 1 within a specified proximity of one another, that the toy-devices be linked via social
  • a toy-health application may have one or
  • the toy-device may have a mouth sensor that monitors for input, such as
  • the metrics may influence abilities
  • the IFP BRIDGE may allow a user to use
  • the user may select "real-world toy control" to play the
  • a user may move/ elevate a real-world toy-device 752 in a manner that the toy is jumping over a curdle.
  • the movement of the real-world toy-device may be transmitted to the virtual-worlds in real time, and is reflected in the virtual-worlds as the toy-avatar may jump over a hurdle shown in the video game.
  • Patent Cooperation Treaty Application No. PCT/USio/23961 filed February 11, 2010, entitled "APPARATUSES, METHODS AND SYSTEMS FOR AN INTERACTIVE PROXIMITY DISPLAY TETHER WITH REMOTE CO-PLAY, is incorporated herein by reference.
  • FIGURES 8A-C provide details on toy-devices and virtual-world (including social network, feed, blog/microblog, etc.) interactions for some embodiments of the IFP BRIDGE.
  • Figure 8A illustrates aspects of the structure of a toy- device, including a bear-shaped body, with embedded GPS/WiFi/ ⁇ G receivers 808, animatronics 805 (e.g. to facilitate eyes, mouth, cheek movement to create facial expressions), speaker/microphone 806, flash memory 820, LCD display 801, and/or the like.
  • the toy-device may have touch sensors on the head, back and the arms 815.
  • FIG. 815 may employ a Phidgets 1110 touch sensor, provides a voltage measure of proximity and pressure. This may be used to detect and interpret proximity/pressure content, as discussed in Figure 6A-B.
  • Figure 8B provides details about virtual-world and social network aspects of a particular implementation of the IFP BRIDGE.
  • the IFP BRIDGE may facilitate a user to configure feed options, settings, friend options, games, status updates, newsfeed, shopping preferences in various applications in social media and networks.
  • the toy-device may be associated with human emulated attributes such as age, health, happiness, hunger, unique IDs, energy, mood 1 and/or the like.
  • Other implementations of the ICFP BRIDGE may include, but are not
  • toy-devices configured as guns or other weapons or tools that allow for
  • Figure 9 provides an overview diagram illustrating an IFP BRIDGE real-
  • a real-world toy-device may have a toy-shaped "body-
  • 10 body-shell may have a core controller chamber 905 to place a processor controller 950
  • the removable components may be docked into the chamber via USB
  • an Android 18 connection, 30 pin docking connector, and/or the like.
  • an Android 18 connection, 30 pin docking connector, and/or the like.
  • an Android 18 connection, 30 pin docking connector, and/or the like.
  • an Android 18 connection, 30 pin docking connector, and/or the like.
  • an Android 18 connection, 30 pin docking connector, and/or the like.
  • the replaceable real-world toy-device may allow a
  • a user may change a toy-avatar in the virtual-worlds from a "bear” to a "rabbit,” the user may desire to change the appearance of the real-world toy-device as well.
  • the user may obtain/purchase a "rabbit" body-shell, which may be more cost-efficient, and fill in the "rabbit" body-shell with electronic components from the "bear” body-shell.
  • the IFP BRIDGE allows an appearance change of the real-world toy-device without any re-registration.
  • a user may purchase a new plug-in component to replace the malfunctioned ones, instead of purchasing a new toy.
  • Figures 10A-J provide example circuit configurations of a toy-device controller in one implementation of the IFP BRIDGE.
  • the hardware specification of components in Figures 10A-J may include and take the form similar to the following component listing:
  • Dual-interface DataFlash AT45DB642 ( N l ( N l ( N l ( N l ( N l ( N l ( N l)
  • FIGURE 11 illustrates inventive aspects of a IFP BRIDGE controller 1101 in a block diagram.
  • the IFP BRIDGE controller 1101 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through wireless transmission and data synchronization technologies, and/or other related data.
  • processors 1103 may be referred to as central processing units (CPU).
  • CPUs central processing units
  • CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations.
  • These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory 1129 (e.g., registers, cache memory, random access memory, etc.).
  • Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations.
  • These stored instruction codes may engage the CPU circuit components and other motherboard and/or system components to perform desired operations.
  • One type of program is a computer operating system, which, may be executed by CPU on a computer; the operating system enables and facilitates users to access and operate computer information technology and resources.
  • Some resources that may be employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed.
  • These information technology systems may be used to collect data for later retrieval, analysis, and manipulation, which may be facilitated through a database program.
  • These information technology systems provide interfaces that allow users to access and operate various system components.
  • the IFP BRIDGE controller 1101 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 1111; peripheral devices 1112; an optional cryptographic processor device 1128; and/or a communications network 1113.
  • entities such as, but not limited to: one or more users from user input devices 1111; peripheral devices 1112; an optional cryptographic processor device 1128; and/or a communications network 1113.
  • Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology.
  • server refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network.
  • Servers serve their information to requesting "clients.”
  • client refers generally to a computer, program, other device, user and/or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network.
  • a computer, other device, program, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a "node.”
  • Networks are generally thought to facilitate the transfer of information from source points to destinations.
  • a node specifically tasked 1 with furthering the passage of information from a source to a destination is commonly
  • LANs Local Area Networks
  • WANs Wide Area Networks
  • WLANs Wireless Networks
  • the Internet is generally accepted as being an interconnection of a
  • the IFP BRIDGE controller 1101 may be based on computer systems that
  • 8 may comprise, but are not limited to, components such as: a computer systemization
  • a computer systemization 1102 may comprise a clock 1130, central
  • CPU(s) and/or “processor(s)” (these terms are used interchangeable
  • a memory 1129 e.g., a
  • ROM read only memory
  • RAM random access memory
  • the computer systemization may be connected to an
  • a cryptographic processor 1126 may be
  • the system clock typically has a crystal oscillator and
  • clock is typically coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization.
  • the clock and various components in a computer systemization drive signals embodying information throughout the system.
  • Such transmission and reception of instructions embodying information throughout a computer systemization may be commonly referred to as communications.
  • These communicative instructions may further be transmitted, received, and the cause of return and/or reply communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like.
  • any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems.
  • the CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests.
  • the processors themselves will incorporate various specialized processing units, such as, but not limited to: integrated system (bus) controllers, memory management control units, floating point units, and even specialized processing sub-units like graphics processing units, digital signal processing units, and/or the like.
  • processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 529 beyond the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc.
  • the processor may access this memory through the use of a memory address space that is accessible via instruction address, which the processor can construct and decode allowing it to access a circuit path to a specific memory address space having a memory state.
  • the CPU may be a microprocessor such as: AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).
  • the CPU interacts with memory through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic and/or optic circuits) to execute stored instructions (e.g.,program code) according to conventional data processing techniques.
  • instruction passing facilitates communication within the IFP BRIDGE controller and beyond through various interfaces.
  • distributed processors e.g., Distributed IFP BRIDGE
  • mainframe multi-core, parallel, and/or super-computer architectures
  • PDAs Personal Digital Assistants
  • features of the IFP BRIDGE may be achieved by implementing a microcontroller such as CAST'S R8051XC2 microcontroller; Intel's MCS 51 (e.g., 8051 microcontroller); and/or the like.
  • a microcontroller such as CAST'S R8051XC2 microcontroller; Intel's MCS 51 (e.g., 8051 microcontroller); and/or the like.
  • some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit (“ASIC”), Digital Signal Processing (“DSP”), Field Programmable Gate Array (“FPGA”), and/or the like embedded technology.
  • ASIC Application-Specific Integrated Circuit
  • DSP Digital Signal Processing
  • FPGA Field Programmable Gate Array
  • any of the IFP BRIDGE component collection (distributed or othereal-worldise) and/or features may be implemented via the microprocessor and/or via embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like.
  • some implementations of the IFP BRIDGE may be implemented with embedded components that are configured and used to achieve a variety of features or signal processing.
  • the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/ software solutions.
  • IFP BRIDGE features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called “logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or the low cost Spartan series manufactured by Xilinx.
  • Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the IFP BRIDGE features.
  • a hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the IFP BRIDGE system designer/administrator, somewhat like a one-chip programmable breadboard.
  • An FPGA's logic blocks can be programmed to perform the function of basic logic gates such as AND, and XOR, or more complex combinational functions such as decoders or simple mathematical functions.
  • the logic blocks also include memory elements, which may be simple flip-flops or more complete blocks of memory.
  • the IFP BRIDGE may be developed on regular FPGAs and then migrated into a fixed version that more resembles ASIC implementations. Alternate or coordinating implementations may migrate IFP BRIDGE controller features to a final ASIC instead of or in addition to FPGAs.
  • all of the aforementioned embedded components and microprocessors may be considered the "CPU" and/or "processor" for the IFP BRIDGE.
  • the power source 1186 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy.
  • the power cell 1186 is connected to at least one of the interconnected subsequent components of the IFP BRIDGE thereby providing an electric current to all subsequent components.
  • the power source 1186 is connected to the system bus component 1104.
  • an outside power source 1186 is provided through a connection across the I/O 1108 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power.
  • Interface bus(ses) 1107 may accept, connect, and/or communicate to a number of interface adapters, conventionally although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) 1108, storage interfaces 1109, network interfaces 1110, and/or the like.
  • cryptographic processor interfaces 1127 similarly may be connected to the interface bus.
  • the interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization.
  • Interface adapters are adapted for a compatible interface bus.
  • Interface adapters conventionally connect to the interface bus via a slot architecture.
  • Conventional slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.
  • AGP Accelerated Graphics Port
  • Card Bus Card Bus
  • E Industry Standard Architecture
  • MCA Micro Channel Architecture
  • NuBus NuBus
  • PCI(X) Peripheral Component Interconnect Express
  • PCMCIA Personal Computer Memory Card International Association
  • Storage interfaces 1109 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 1114, removable disc devices, and/or the like.
  • Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
  • connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
  • Network interfaces 1110 may accept, communicate, and/or connect to a communications network 1113.
  • the IFP BRIDGE controller is accessible through remote clients 1133b (e.g., computers with web browsers) by users 1133a.
  • Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 8 ⁇ 2.na-x, and/or the like.
  • a communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like.
  • WAP Wireless Application Protocol
  • a network interface may be regarded as a specialized form of an input output interface. Further, multiple network interfaces mo may be used to engage with various communications network types 1113. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks.
  • I/O 1108 may accept, communicate, and/or connect to user input devices 1111, peripheral devices 1112, cryptographic processor devices 1128, and/or the like.
  • I/O may employ connection protocols such as, but not limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus (ADB), IEEE I394a-b, serial, universal serial bus (USB); infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface: Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless: 802.na/b/g/n/x, Bluetooth, code division multiple access (CDMA), global system for mobile communications (GSM), WiMax, etc.; and/or the like.
  • ADC Apple Desktop Connector
  • DVI Digital Visual Interface
  • HDMI
  • One typical output device may include a video display, which typically comprises a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may be used.
  • the video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame.
  • Another output device is a television set, which accepts signals 1 from a video interface.
  • the video interface provides the composited video
  • User input devices mi may be card readers, dongles, finger print readers,
  • Peripheral devices 1112 may be connected and/or communicate to I/O
  • Peripheral devices may be audio devices, cameras, dongles (e.g., for copy
  • the IFP BRIDGE controller may be embodied as an embedded
  • Cryptographic units such as, but not limited to, microcontrollers,
  • processors 1126, interfaces 1127, and/or devices 1128 may be attached, and/or
  • 23 MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the i6 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation.
  • Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions.
  • Cryptographic units may also be configured as part of CPU. Equivalent microcontrollers and/or processors may also be used.
  • Typical commercially available specialized cryptographic processors include: the Broadcom's CryptoNetX and other Security Processors; nCipher's nShield, SafeNet's Luna PCI (e.g., 7100) series; Semaphore Communications' 40 MHz Roadrunner 184; Sun's Cryptographic Accelerators (e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); Via Nano Processor (e.g., L2100, L2200, U2400) line, which is capable of performing 500+ MB/s of cryptographic instructions; VLSI Technology's 33 MHz 6868; and/or the like.
  • the Broadcom's CryptoNetX and other Security Processors include: the Broadcom's CryptoNetX and other Security Processors; nCipher's nShield, SafeNet's Luna PCI (e.g., 7100) series; Semaphore Communications' 40 MHz Roadrunner 184; Sun's Cryptographic Accelerators
  • any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory 1129.
  • memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another.
  • the IFP BRIDGE controller and/or a computer systemization may employ various forms of memory 1129.
  • a computer systemization may be configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage devices are provided by a paper punch tape or paper punch card mechanism; of course such an embodiment would result in an extremely slow rate of operation.
  • memory 1129 will include ROM 1106, RAM 1105, and a storage device 1114.
  • a storage device 1114 may be any conventional computer system storage. Storage devices may include a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (e.g.,Blueray, CD ROM/RAM/Recordable (R)/ReWritable (real-world), DVD R/real-world, HD DVD R/real-world etc.); an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable storage mediums; and/or other devices of the like.
  • a computer systemization generally requires and makes use of memory.
  • the memory 1129 may contain a collection of program and/or database components and/or data such as, but not limited to: operating system component(s) 1115 (operating system); information server component(s) 1116 (information server); user interface component(s) 1117 (user interface); Web browser component(s) 1118 (Web browser); database(s) 1119; mail server component(s) 1121; mail client component(s) 1122; cryptographic server component(s) 1120 (cryptographic server); the IFP BRIDGE component(s) 1135; and/or the like (e.g., collectively a component collection). These components may be stored and accessed from the storage devices and/or from storage devices accessible through an interface bus.
  • operating system component(s) 1115 operating system
  • information server component(s) 1116 information server
  • user interface component(s) 1117 user interface
  • Web browser component(s) 1118 Web browser
  • database(s) 1119 mail server component(s) 1121; mail client component(s) 1122; cryptographic server component(s) 11
  • the operating system component 1115 is an executable program component facilitating the operation of the IFP BRIDGE controller. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/ or the like.
  • the operating system may be a highly fault tolerant, scalable, and secure system such as: Apple Macintosh OS X (Server); AT&T Plan 9; Be OS; Unix and Unix-like system distributions (such as AT&T's UNIX; Berkley Software Distribution (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating systems.
  • Apple Macintosh OS X Server
  • AT&T Plan 9 Be OS
  • Unix and Unix-like system distributions such as AT&T's UNIX
  • Berkley Software Distribution (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like
  • Linux distributions such as Red Hat, Ubuntu, and/or the like
  • an operating system may communicate to and/or with other components in a component collection, including itself, and/or the like. Most frequently, the operating system communicates with other program components, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
  • the operating system may enable the interaction with communications networks, data, I/O, peripheral devices, program components, memory, user input devices, and/or the like.
  • the operating system may provide communications protocols that allow the IFP BRIDGE controller to communicate with other entities through a communications network 1113.
  • Various communication protocols may be used by the IFP BRIDGE controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/ or the like.
  • An information server component 1116 is a stored program component that is executed by a CPU.
  • the information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the like.
  • the information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like.
  • ASP Active Server Page
  • ActiveX ActiveX
  • ANSI Objective-
  • C++ C#
  • CGI Common Gateway Interface
  • CGI Common Gateway Interface
  • D hypertext markup language
  • FLASH Java
  • JavaScript JavaScript
  • PROL Practical Extraction Report Language
  • PGP
  • the information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (e.g., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo!
  • FTP File Transfer Protocol
  • HTTP HyperText Transfer Protocol
  • HTTPS Secure Hypertext Transfer Protocol
  • SSL Secure Socket Layer
  • messaging protocols e.g., America Online (A
  • the information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components.
  • DNS Domain Name System
  • the information server resolves requests for information at specified locations on the IFP BRIDGE controller based on the remainder of the HTTP request.
  • a request such as http://123.124.125.126/mylnformation.html might have the IP portion of the request "123.124.125.126” resolved by a DNS server to an information server at that IP address; that information server might in turn further parse the http request for the "/mylnformation.html” portion of the request and resolve it to a location in memory containing the information "mylnformation.html.”
  • other information serving protocols may be employed across various ports, e.g., FTP communications across port 21, and/or the like.
  • An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the information server communicates with the IFP BRIDGE database 1119, operating systems, other program components, user interfaces, Web browsers, and/or the like.
  • Access to the IFP BRIDGE database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the IFP BRIDGE.
  • the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields.
  • the parser may generate queries in standard SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the IFP BRIDGE as a query.
  • the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser.
  • an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
  • Computer interfaces The function of computer interfaces in some respects is similar to automobile operation interfaces.
  • Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, functionality, and status.
  • Computer interaction interface elements such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) similarly facilitate the access, operation, and display of data and computer hardware and operating system resources, functionality, and status. Operation interfaces are commonly called user interfaces.
  • GUIs Graphical user interfaces
  • GUIs such as the Apple Macintosh Operating System's Aqua, IBM's OS/2, Microsoft's Windows 2OOO/2OO3/3-i/95/98/CE/Millenium/NT/XP/Vista/7 (e.g.,Aero), Unix's X-Windows (e.g., which may include additional Unix graphic interface libraries and layers such as K Desktop Environment (KDE), mythTV and GNU Network Object Model Environment (GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc.
  • KDE K Desktop Environment
  • GNOME GNU Network Object Model Environment
  • web interface libraries e.g., ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc.
  • a user interface component 1117 is a stored program component that is executed by a CPU.
  • the user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as already discussed.
  • the user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities.
  • the user interface provides a facility through which users may affect, interact, and/or operate a computer system.
  • a user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like.
  • the user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
  • Web Browser [o o ii3]
  • a Web browser component 1118 is a stored program component that is executed by a CPU.
  • the Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator.
  • Secure Web browsing may be supplied with I28bit (or greater) encryption by way of HTTPS, SSL, and/or the like.
  • Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the like.
  • Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices.
  • a Web browser may communicate to and/or with other components in a component collection, including itself, and/ or facilities of the like.
  • the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
  • information servers operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
  • a combined application may be developed to perform similar functions of both.
  • the combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the IFP BRIDGE enabled nodes.
  • the combined application may be nugatory on systems employing standard Web browsers.
  • a mail server component 1121 is a stored program component that is executed by a CPU 1103.
  • the mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and/or the like.
  • the mail server may allow for the execution of program components through facilities such asASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like.
  • the mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like.
  • IMAP Internet message access protocol
  • MAPI Messaging Application Programming Interface
  • PMP3 post office protocol
  • simple mail transfer protocol SMTP
  • the mail server can route, foreal-worldard, and process incoming and outgoing mail messages that have been sent, relayed and/or othereal- worldise traversing through and/or to the IFP BRIDGE.
  • Access to the IFP BRIDGE mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system.
  • a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
  • a mail client component 1122 is a stored program component that is executed by a CPU 1103.
  • the mail client may be a conventional mail viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like.
  • Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like.
  • a mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like.
  • the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/ or responses.
  • the mail client provides a facility to compose and transmit electronic mail messages.
  • a cryptographic server component 1120 is a stored program component that is executed by a CPU 1103, cryptographic processor 1126, cryptographic processor interface 1127, cryptographic processor device 1128, and/or the like. Cryptographic processor interfaces will allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a conventional CPU.
  • the cryptographic component allows for the encryption and/or decryption of provided data.
  • the cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption.
  • PGP Pretty Good Protection
  • the cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/ or the like.
  • the cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like.
  • digital certificates e.g., X.509 authentication
  • the IFP BRIDGE may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network.
  • the cryptographic component facilitates the process of "security authorization" whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource.
  • the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for an digital audio file.
  • a cryptographic component may communicate to and/or with other components in a component collection, including itself, and/ or facilities of the like.
  • the cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable the IFP BRIDGE component to engage in secure transactions if so desired.
  • the cryptographic component facilitates the secure accessing of resources on the IFP BRIDGE and facilitates the access of secured resources on remote systems; e.g.,it may act as a client and/or server of secured resources.
  • the cryptographic component communicates with information servers, operating systems, other program components, and/or the like.
  • the cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
  • the IFP BRIDGE database component 1119 may be embodied in a database and its stored data.
  • the database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored data.
  • the database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase.
  • Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; e.g., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys.
  • Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the "one" side of a one-to-many relationship.
  • the IFP BRIDGE database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files.
  • an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like.
  • Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of functionality encapsulated within a given object. If the IFP BRIDGE database is implemented as a data-structure, the use of the IFP BRIDGE database 1119 may be integrated into another component such as the IFP BRIDGE component 1135. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques.
  • the database component 1119 includes several tables uigsL-e.
  • An applications table 1119a includes fields such as, but not limited to: application_ID, application_name, settings, configurations, saved_states, sensor_inputs, application_data, and/or the like.
  • a Protocols table 1119b may include fields such as, but not limited to: protocol_ID, protocol_name, protocol_type, format, access_data, server_data, device_configuration, avatar_configuration, and/or the like.
  • a device table 1119c may include fields such as, but not limited to: device_ID, device_parameters, device_type, device_data, configuration, and/or the like.
  • An account table ni9d may include fields such as, but not limited to: account_ID, account_profile, account_parameters, account_avatar, account_data, configuration, and/or the like.
  • a virtual-world table ni9e may include fields such as, but not limited to: virtual-world_ID, virtual-world_parameters, virtual-world_name, virtual- world_data, virtual-world_configuration, and/or the like.
  • a sensor table ni9f may include fields such as, but not limited to: sensor_ID, sensor_parameters, sensor_type, sensor_data, sensor_configuration, sensor_history, and/or the like.
  • a user table ni9g may support and/or track multiple entity accounts on a IFP BRIDGE, and includes fields such as, but not limited to: user_ID, user_name, user_account_type, user_pasword, toy_ID, toy_hardware, application_authorization_info, account_info, and/or the like.
  • An actions table 1019I1 may define IFP BRIDGE actions and the associated responses, including fields such as, but not limited to: action_ID, action_name, sensor_ID, action_parameters, toy_ID, action_response, action_msg, action_response_sensor, and/or the like.
  • the IFP BRIDGE database may interact with other database systems. For example, employing a distributed database system, queries and data access by search IFP BRIDGE component may treat the combination of the IFP BRIDGE database, an integrated data security layer database as a single database entity.
  • user programs may contain various user interface primitives, which may serve to update the IFP BRIDGE.
  • various accounts may require custom database tables depending upon the environments and the types of clients the IFP BRIDGE may need to serve. It should be noted that any unique fields may be designated as a key field throughout.
  • these tables have been decentralized into their own databases and their respective database controllers (e.g., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components ni9a-h.
  • the IFP BRIDGE may be configured to keep track of various settings, inputs, and parameters via database controllers.
  • the IFP BRIDGE database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the IFP BRIDGE database communicates with the IFP BRIDGE component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data.
  • the IFP BRIDGE component 1135 is a stored program component that is executed by a CPU.
  • the IFP BRIDGE component incorporates any and/or all combinations of the aspects of the IFP BRIDGE that was discussed in the previous figures. As such, the IFP BRIDGE affects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks.
  • the IFP BRIDGE component enables the real-world-virtual-world interactions and data synchronization and/or the like and use of the IFP BRIDGE.
  • the IFP BRIDGE component enabling access of information between nodes may be developed by employing standard development tools and languages such as, but not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI) (Objective-) C (++), C# and/or .NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, procedural and object oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, web application server extensions, web development environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo!
  • Apache components Assembly, ActiveX, binary executables, (ANSI) (Objective-) C (++), C# and/or .NET
  • database adapters CGI scripts
  • Java JavaScript
  • mapping tools procedura
  • the IFP BRIDGE server employs a cryptographic server to encrypt and decrypt communications.
  • the IFP BRIDGE component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the IFP BRIDGE component communicates with the IFP BRIDGE database, operating systems, other program components, and/or the like.
  • the IFP BRIDGE may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
  • IFP BRIDGE node controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/ or deployment.
  • component collection may be combined in any number of ways to facilitate deployment and/or development. To accomplish this, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion.
  • the component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques. [00130] The configuration of the IFP BRIDGE controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration.
  • data may be communicated, obtained, and/or provided.
  • Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like.
  • component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), local and remote application program interfaces Jini, Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like.
  • API Application Program Interfaces
  • DCOM Component Object Model
  • D Distributed) Object Linking and Embedding
  • CORBA Common Object Request Broker Architecture
  • Jini Remote Method Invocation
  • SOAP process pipes, shared files, and/or the like.
  • a grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing functionality, which in turn may form the basis of communication messages within and between components.
  • a grammar may be arranged to recognize the tokens of an HTTP post command, e.g.: w3c -post http : // . . . V ⁇ luel
  • Valuei is discerned as being a parameter because "http://" is part of the grammar syntax, and what follows is considered part of the post value. Similarly, with such a grammar, a variable "Valuei" may be inserted into an "http://" post command and then sent.
  • the grammar syntax itself may be presented as structured data that is interpreted and/or other wise used to generate the parsing mechanism (e.g., a syntax description text file as processed by lex, yacc, etc.).
  • parsing mechanism may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data.
  • character e.g., tab
  • inter-application data processing protocols themselves may have integrated and/or readily available parsers (e.g., the SOAP parser) that may be employed to parse communications data.
  • the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment.
  • IFP BRIDGE IFP BRIDGE
  • associated devices applications, control configurations, interface devices, associated data, communication and/or network frameworks, hardware configurations, monetization models, and/or the like
  • various embodiments of the IFP BRIDGE may be implemented that enable a great deal of flexibility and customization.
  • the instant disclosure discusses embodiments and/ or applications of the IFP BRIDGE directed to interactions between toys, social networks, and/or computer generated environments.
  • the system described herein may be readily configured and/or customized for a wide range of other applications and/or implementations.
  • aspects of the IFP BRIDGE may be adapted for non-toy related interaction applications; include additional and/or alternative types of monitoring (e.g., security) and/or sensors (e.g., face recognition, location, temperature, pressure, position, elevation, sound/light intensity, and/or the like); and/or the like applications and/or components. It is to be understood that the IFP BRIDGE may be further adapted to other implementations or communication, interface, and/or control applications. [00135] As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments.

Abstract

The APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE ("IFP BRIDGE") facilitates interactions and communications in the real world, and between the real world and one or more computer generated environments, including social networks, blogs/microblogs, virtual environments, and the like. In some embodiments, the interactions may be triggered by some external signal, such as a received instruction or environmental cue. In some embodiments, the IFP BRIDGE coordinates interactions between a real world toy-device and a social network component and/or corresponding toy-avatar in one or more computer generated environments. Similarly, in certain implementations, the ICFP BRIDGE monitors the action/interactions in a social network and/or of a toy-avatar in the computer generated environment and determines and executes appropriate response actions for the toy-device in the real world.

Description

APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE
RELATED APPLICATIONS
[o o o i] Applicant hereby claims priority under 35 USC §119 for United States provisional patent application serial no. 61/152,595, filed February 13, 2009, entitled "APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE," attorney docket no. 19626-005PV, and United States provisional patent application serial no. 61/219,526, filed June 23, 2009, entitled "APPARATUSES, METHODS AND SYSTEMS FOR AN INTERACTIVE COMMUNICATION FEEDBACK PLATFORM BRIDGE," attorney docket no. 19626-007PV. [0002] Applicant hereby claims priority to Patent Cooperation Treaty patent application serial no. PCT/USio/23961, filed February 11, 2010, entitled "APPARATUSES, METHODS AND SYSTEMS FOR AN INTERACTIVE PROXIMITY DISPLAY TETHER WITH REMOTE CO-PLAY," attorney docket no. 19626-004PC.
[0003] The entire contents of the aforementioned applications are herein expressly incorporated by reference.
FIELD
[0004] The present invention is directed generally to an apparatuses, methods, and systems of enhancing user interaction and communication across different environments, and more particularly, to APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE.
BACKGROUND
[0005] Social networks allow users to identify and communicate with each other via home computers, either socially (e.g., Facebook, MySpace) or professionally (e.g., Linkedlή). Computer-based simulations allow users to inhabit and interact in simulated digital environments. Simulated environments may be three-dimensional and may include simulated or generated characters that represent users. Some simulated environments may function as games (e.g., World of Warcrqft), while others are more like the real world (e.g., Second Life). Users access and interact with these simulated environments via home computers and video game consoles. Some toys, such as Webkinz, provide a unique identifier along with the purchase of a static physical toy, that acts as a password to allow users to access a simulated environment..
SUMMARY
[0006] This disclosure details aspects of APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE (hereinafter, "IFP BRIDGE"). The IFP BRIDGE facilitates interactions and communications, between devices in the real world ("real-world"), and in some embodiments, between the real-world and one or more social networks and/or other computer generated environments ("virtual-worlds") (e.g., virtual realities/ worlds). The IFP BRIDGE may associate a first real-world toy-device with a second real-world toy-device, and coordinate interactions between the toy-devices. In some embodiments, the interactions may be triggered by some external signal, such as a received instruction or environmental cue. In some embodiments, the IFP BRIDGE coordinates interactions between a real-world toy-device and a social network component and/or corresponding toy-avatar in one or more virtual-worlds. Subsequent user interactions with the real-world toy-device are monitored and may influence aspects of a profile in a social network and or a toy-avatar in a virtual-world. Similarly, in certain implementations, the IFP BRIDGE monitors the action/interactions in a social network and/or of a toy-avatar in the virtual-world and determines and executes appropriate response actions for the toy-device in the real -world.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The accompanying drawings illustrate various non-limiting, example, inventive aspects in accordance with the present disclosure: [0008] FIGURE 1 is an overview diagram illustrating an implementation of an embodiment of the APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE (hereinafter "IFP BRIDGE"); [0009] FIGURE 2 discloses aspects of component implementation for an embodiment of the IFP BRIDGE; [0010] FIGURE 3 is a logic flow diagram illustrating aspects of an embodiment of the IFP BRIDGE; [o o ii] FIGURE 4A-B are logic flow diagrams illustrating aspects of real-world toy-device registration within an embodiment of the IFP BRIDGE;
[0012] FIGURE 5A-B provide logic flow diagrams illustrating aspects of real- world-virtual-world interactions within an embodiment of the IFP BRIDGE;
[0013] FIGURE 6A-B are logic flow diagrams illustrating aspects of an alternative embodiment of the IFP BRIDGE;
[0014] FIGURES 7A-C provide example screen shots illustrating aspects of different implementations of IFP BRIDGE;
[0015] FIGURES 8A-B provide example specification details on toy-devices and virtual-worlds within one embodiment of IFP BRIDGE;
[0016] FIGURE 9 provides an overview diagram illustrating an IFP BRIDGE real- world toy-device with replaceable electronic components in one embodiment of IFP BRIDGE;
[0017] FIGURES 10A-J provide example circuit diagrams illustrating implementations of an IFP BRDIGE toy-device controller in one embodiment of IFP BRIDGE; and
[0018] FIGURE 11 is of a block diagram illustrating embodiments of the IFP BRIDGE controller.
[0019] The leading number of each reference number within the drawings indicates the figure in which that reference number is introduced and/or detailed. As such, a detailed discussion of reference number 101 would be found and/or introduced in Figure 1. Reference number 201 is introduced in Figure 2, etc. DETAILED DESCRIPTION
IFP BRIDGE [O O 2O] This disclosure details aspects of APPARATUSES, METHODS AND SYSTEMS FOR AN INTERWORLD FEEDBACK PLATFORM BRIDGE (hereinafter, "IFP BRIDGE"). In some embodiments, IFP BRIDGE may serve to facilitate and coordinate interactions and communications between multiple devices in the real world ("real- world"). In some embodiments, the IFP BRIDGE may facilitate and coordinate interactions and communications between one or more device in the real-world and one or more social networks and/or computer generated environments ("virtual- worlds"). [0021] In one embodiment, an IFP BRIDGE real -wo rid toy-device may take a similar look with a stuffed toy (e.g., a bear, a rabbit, etc.) but having a processor in controlling various built-in electronics, such as animatronics (e.g., movable eyes, mouth, cheeks, etc.), speaker/microphones, wireless receivers, LCD display, sensors, accelerometers, and/or the like. In one implementation, the real-world toy-device may register with an application in the IFP BRIDGE virtual-worlds via wireless connections to associate with a corresponding toy-avatar, e.g., a video game, a virtual community, etc., and exchange data with the virtual -worlds to synchronize the status of the real-world toy-device and the virtual-world toy-avatar.
[0022] For example, in one implementation, if the real- world toy-device senses a physical hug from a user, the real-world toy-device may show a smile by controlling mouth movement through its animatronics, and send electronic data describing its 1 current status, e.g., "Hugged: Happy," to the virtual-worlds. In one implementation,
2 the virtual-worlds may update the status associated with the profile of the toy-avatar
3 as "Hugged: Happy." In another implementation, if a user modifies the status of a
4 toy-avatar via the virtual-worlds, e.g., by selecting an option of "Hug," the toy-avatar
5 may show an updated status as "Hugged: Happy" and in turn send the status updates
6 to the real-world toy-device. In one implementation, the real-world toy-device may
7 receive the status updates of "Hugged: Happy" and then respond accordingly as it is
8 physically hugged by a user, e.g., showing a smile.
9 [0023] FIGURE 1 is of a block diagram illustrating an overview of an
10 implementation of data flows between an IFP BRIDGE system and affiliated entities in
11 one embodiment of the IFP BRIDGE operation. In Figure 1, real-world toy-device 101a-
12 b, user devices 115-117, an IFP BRIDGE server 120, a crowdsourcing server 128, a social
13 network server 127, a blog/microblog server 126, an IFP BRIDGE database 119, and a
14 system administrator are shown to interact via a communication network 110.
15 [0024] In some implementations of the IFP BRIDGE, a real-world toy-device
16 101a is registered with the IFP BRIDGE via a user device 115. For example, the user
17 device 115 may include a wide variety of different devices and technologies such as, but
18 not limited to mobile devices, gaming terminals, computers, general computing devices,
19 and/or the like. In one implementation, a real-world toy-device 101a is automatically
20 registered with ICP BRDIGE. For example, in one implementation, the real-world toy-
21 device may connect to a home computer 115 via a local area network 105a, such as
22 Bluetooth, 3G, Wi-Fi or the like, and transmit an activation notification to the IFP
23 BRIDGE for registration. In one implementation, the IFP BRIDGE may register a real-world toy-device by identifying information such as, but not limited to physical address (e.g., MAC address), IP address, hardware identification, network acronym, and/or the like. [O O 25] In other implementations, a user may activate, configure, and register the toy-device ioia, for example, via a user device 115. In such an implementation, a registration interface may have fields (e.g., lisa-use) that allow a user to enter a name for the toy-device, an email address, an owner name, password, associated virtual- world account(s) (e.g., Facebook, MySpace, SecondLife, Twitter, etc.) and/or the like, that is stored and registered at the IFP BRIDGE server 120. In one embodiment, a password may be used to make a digital certificate encrypted key (and/or the like) for providing enhanced security between the toy-device and the server. The interface may also allow a user to upload a picture or pictures (for example, for use in subsequent face recognition by the toy-device). In some embodiments, IFP BRIDGE may allow a user to access the online profile of the real-world toy-device 101a and configure the toy-avatar in the virtual-worldi32/i25-i28. As shown in Figure 1, the IFP BRIDGE may provide the user with a view of their toy-avatar 102a (e.g., via a virtual-world interface on the user's laptop or home computer 116), status (e.g., via a social network or blog/microblog update interface 117a on the user's laptop, home computer, cell phone, PDA, etc.), and/or the like, and may provide similar views/information to other users of the virtual-worlds. [0026] Depending on the embodiment, a corresponding account may be created and/or linked to in a social network running on one or more servers, a corresponding toy-avatar may be created or activated in a virtual-world running on one or more 1 servers, and/or the real -world toy-device ioia may be linked to a second real -world
2 toy-device ioib. Depending on the embodiment, a social network, blog/microblog,
3 crowdsourcing site, virtual-world, and/or the like (hereinafter "virtual-worlds") 132
4 (and/or associated applications/components) may be associated with the one or more
5 IFP BRIDGE servers 120, while in other embodiments virtual-worlds may be
6 independent and may have their own servers 125-128.
7 [o o 27] In some embodiments, subsequent interactions with the real-world toy-
8 device 101a are monitored 134 by the IFP BRIDGE and, depending on the interactions,
9 may influence the aspects (status, appearance, and/or other attributes) of the toy-avatar
10 102a in the virtual-worlds 132/125. Other interactions and/or applications may also be
11 made available 136, including, but not limited to, subscription or pay services or
12 utilities. In one embodiment, the IFP BRIDGE utilizes real-world toy-devices that
13 contain integrated communications network adapter modules (e.g., cellular, Bluetooth,
14 WiFi, etc.), touch sensors, motion sensors, audio/video recorders, accelerometers,
15 and/or like sensors. In one such implementation, a user stimulating the sensors (e.g.,
16 hugging or petting the toy-device in the real-world) may cause changes in an application
17 state for an application running on the toy-device 101 and/or one or more servers 120,
18 125-128. The toy-device may contain integrated components that provide
19 communication capabilities that allow the toy-device 101 to send signals via a
20 communications network 110 to one or more servers 120. The communications network
21 110 may, for example, comprise a mobile data network, local area network, the internet,
22 cable connection, WiFi, Bluetooth, and/or the like. 1 [O O 28] When the IFP BRIDGE registers toy-device sensor information (e.g.,
2 changes in an application state), instructions may be issued to the social network,
3 blog/microblog, toy-avatar, and/or the like to change/update status, appearance,
4 and/or other characteristics. For example, when the IFP BRIDGE registers 134 hugging
5 or petting of the toy-device 101a in the real-world, instruction may be issued causing to
6 an associated social networking site 132/127 or microblog 132/126 to update status to
7 "hugged" or "Happy", cause an associated toy-avatar 102a to smile in the virtual-world
8 132/125, and/or the like.
9 [0029] Similarly, in some implementations, the IFP BRIDGE monitors the
10 actions/interactions of a social network account 132/127 and/or of the toy-avatar in
11 the virtual- world 132/125 and determines, based on a set of criteria, appropriate
12 response actions for the toy-device 101a in the real-world. For example, a post or
13 received message on a social networking site may be transmitted to the toy-device and
14 deliver, for example, via speech-to-text, to the user of the toy device. In another
15 example, if the toy-avatar encounters another toy-avatar that is designated as a friend
16 (e.g., as indicated by both toy-avatars being associated with a particular social
17 network), the IFP BRIDGE may transmit instructions to toy-device that cause the eyes
18 of the toy-device 101 to glow.
19 [O O 3O] In one embodiment, the IFP BRIDGE entities such as the user devices 115-
20 117, the real-world toy-device 101a, the IFP BRIDGE server 120, the virtual-worlds
21 servers 125-128, and/or the like, may also communicate with an IFP BRIDGE database
22 119. In some embodiments, distributed IFP BRIDGE databases may be integrated in-
23 house with the IFP BRIDGE server 120, and/or the virtual-world servers 125. In other embodiments, the IFP BRIDGE entities may access a remote IFP BRIDGE database 119 via the communication network 110. In one embodiment, the IFP BRIDGE entities may send data to the database 119 for storage, such as, but not limited to user account information, toy profile information, hardware information, application data, protocol data, application history, and/or the like. [o o 3i] In one embodiment, the IFP BRIDGE database 119 may be one or more online database connected to a variety of vendors, such as hardware vendors (e.g. Apple Inc. , Intel, Sony, etc.), application vendors (e.g. ToyBots, Nintendo, Game Cube, Game Boy, etc.) , virtual world service vendors (e.g. ActiveWorlds, Second Life, etc.), social media vendors (e.g., SGN, Twitter, Facebook, MySpace, etc.), and/or the like, and obtain updated hardware driver information, updated application packages, news feeds and services from such vendors. In one embodiment, the real-world toy-devices ioia-b, user devices 115-117, the IFP BRIDGE server 130 and/ or the virtual-worlds servers 125-128 may constantly, intermittently, and/or periodically download updates, such as updated user profile, updated software programs, updated command instructions, and/or the like, from the IFP BRIDGE database 119 via a variety of connection protocols, such as Telnet FTP, HTTP transfer, P2P transmission and/or the like.
[0032] In one embodiment, a system administrator may communicate with the IFP BRIDGE entities for regular maintenance, service failure, system updates, database renewal, security surveillance and/ or the like via the communication network 110. For example, in one implementation, the system administrator may be a user, who may directly operate with home computers 115-117 to configure system settings, parental control, and/or the like. In another implementation, the system administrator may be an IFP BRIDGE administrator operating with the IFP BRIDGE server 120 to monitor the IFP BRIDGE system.
[0033] FIGURE 2 shows an implementation of IFP BRIDGE system components for the toy-device in one embodiment of IFP BRIDGE operation. The toy-device 201 may contain a number of functional modules and/ or data stores. A toy-device IFP BRIDGE controller 205 may serve a central role in some embodiments of IFP BRIDGE operation, serving to orchestrate the reception, generation, and distribution of data and/or instructions to, from and between IFP BRIDGE modules and/or mediate communications with external entities, systems, servers, and/or environments.
[0034] In one embodiment, the IFP BRIDGE controller 205 may be housed separately from other modules and/or databases within the IFP BRIDGE system, while in another embodiment, some or all of the other modules and/or databases may be housed within and/or configured as part of the IFP BRIDGE controller. Further detail regarding implementations of IFP BRIDGE controller operations, modules, and databases is provided below.
[0035] In one implementation, the toy-device IFP BRIDGE Controller may be coupled to one or more interaction components and/or functional modules (sensors, interaction interfaces, and/or the like). For example, the toy-device IFP BRIDGE may be coupled to an audio I/O (input/ output) 225a, video I/O 225b, location sensor(s) 225c (e.g., GPS, location triangulation, etc.), touch sensor(s) 225d, movement sensor(s) 225e (e.g., accelerometer), interaction I/O 225f (animatronics, interfaces, responsive servos, and/or the like), and/or other sensor I/O 225g. In some embodiments, a further user interface (UI) may be provided and configured to receive user inputs and display 1 application states and/or other outputs. The UI may, for example, allow a user to adjust
2 IFP BRIDGE system settings, select communication methods and/or protocols, initiate
3 a remote display mode, engage mobile device application features, identify possible
4 target/ client device(s) and/or the like. In one implementation, the user interface 210
5 may include, but not limited to devices such as, keyboard(s), mouse, stylus(es), touch
6 screen(s), digital display(s), and/or the like. In some embodiments, a UI may be
7 accessed by a user over a communications I/O.
8 [0036] In one implementation, the toy-device IFP BRIDGE Controller may
9 further be coupled to an applications engine 215, configured to toy-device application
10 software. The applications engine 215 may receive sensory input information
11 originating from the integrated sensors/interfaces (225a-225g) and interpret the
12 information to update the configuration of an application state. In an implementation
13 the updated application state data may be transferred a user device (a home computer),
14 and/or IFP BRIDGE servers. For example, an application run by the applications
15 engine may comprise an "Electronic Pet" gaming platform, which may provide "petting"
16 instructions, such as "The pet needs to be fed", etc., and the "Mood" of the "Electronic
17 Pet," such as "Hungry," "Sick," etc., to a user via a user I/O interface (e.g., the video I/O
18 225A and/or the video I/O 225B).
19 [o 037] As discussed above, in some implementations, the toy-device IFP BRIDGE
20 Controller 205 may be coupled to an interaction module 220, configured to interface
21 with and/or process signals to/from interaction/sensor input/output (I/O) components
22 225a-225g. The interaction/sensor I/O components 225a-225g may be stimulated by
23 user interaction/manipulation, environmental conditions, location, and/ or the like to 1 generate electrical signals that may be received and/ or processed by the interactions
2 module 220 and/or other toy-device IFP BRIDGE components. A wide variety of
3 different interaction/sensors may be compatible with toy-device IFP BRIDGE operation
4 and may be integrated with interaction/sensor I/O components 225a-225g, such as but
5 not limited to transducers, accelerometers, thermometers, anemometers, barometers,
6 microphones, cameras, location sensors, responsive servos, and/ or the like, configured
7 to measure states of motion, sound level, volume, pitch, pressure, wind speed,
8 temperature, data transfer rate, light intensity level, position, elevation, location,
9 moisture level, humidity, and/or the like. In one implementation, the
10 interaction/sensor module 220 configures signals received from the interaction/sensor
11 I/O components 225a-225g in a form suitable for an application being run by the
12 applications engine 215. In an alternative implementation, the applications engine 215
13 may receive signals directly from interaction/sensor I/O components 225a-225g for
14 processing to update an application state for one or more running applications.
15 [0038] In one implementation, the toy-device IFP BRIDGE Controller 205 may
16 further be coupled to a communications module 230, configured to interface with
17 and/or process signals from communications I/O components 235. The
18 communications I/O components 235 may comprise components facilitating
19 transmission of electronic communications via a variety of different communication
20 protocols and/or formats as coordinated with and/or by the communications module
21 230. Communication I/O components 240 may, for example, contain ports, slots,
22 antennas, amplifiers, and/or the like to facilitate transmission of interaction
23 instructions/ status, such as interaction/sensor status and/or toy-device application
24 state(s), via any of the aforementioned methods. Communication protocols and/or formats for which the communications module 230 and/or communications I/O components 235 may be compatible may include, but are not limited to, GSM, GPRS, 3G EDGE, W-CDMA, CDMA, CDMA2000, HSDPA, Ethernet, WiFi, Bluetooth, USB, and/or the like. In various implementations, the communication I/O 235 may, for example, serve to configure data into application, transport, network, media access control, and/or physical layer formats in accordance with a network transmission protocol, such as, but not limited to FTP, TCP/IP, SMTP, Short Message Peer-to-Peer (SMPP) and/or the like. The communications module 230 and communications I/O 235 may further be configurable to implement and/or translate Wireless Application Protocol (WAP), VoIP and/or the like data formats and/or protocols. The communications I/O 235 may further house one or more ports, jacks, antennas, and/or the like to facilitate wired and/or wireless communications with and/or within the IFP BRIDGE system. For example, in the above "Electronic Pet" example, the IFP BRIDGE controller 205 may transmit the received sensor data characteristics of the motion of the toy-device, which may be interpreted as "Hug," "Feed," etc., to the communication module 230, and the data may then be transmitted to external entities (e.g. the IFP BRIDGE server, etc.) through the communications I/O 235.
[0039] Numerous data transfer protocols may be employed upon such connections, for example, TCP/IP and/ or higher protocols such as HTTP post, FTP put commands, and/or the like. In one implementation, the communications module 230 may comprise web server software, e.g., Apache, equipped to configure application state data for publication on the World Wide Web. Published application state data may, in one implementation, be represented as an integrated video, animation, rich internet 1 application, virtual-world data, and/or the like, and may be configured in accordance
2 with a multimedia plug-in, such as Adobe Flash.
3 [o θ4θ] In one implementation, the toy-device IFP BRIDGE controller 205 may
4 further be coupled to a plurality of databases configured to store and maintain toy-
5 device IFP BRIDGE data. An applications database 240 may contain application data,
6 settings, configurations, games, game states, status data, interactions data, social data,
7 application interface elements, and/or the like. A protocols database 245 may contain
8 data pertaining to communication protocols and/ or data configurations for one or more
9 virtual-worlds, suitable for publication on the World Wide Web, sharing between client
10 and server devices in a remote-access software setup, and/or the like. A toys database
11 246 may contain data pertaining to toy-device hardware data, toy-device account data in
12 the virtual-worlds, associated application history, system configurations, and/or the
13 like.
14 [0041] In one implementation, the IFP BRIDGE controller may be further
15 coupled to a user database, containing information pertaining to account information,
16 contact information, profile information, identities of hardware devices, Customer
17 Premise Equipments (CPEs), and/or the like associated with users, application history,
18 system configurations, and/or the like. A hardware database may contain information
19 pertaining to hardware devices with which the IFP BRIDGE system may communicate,
20 such as but not limited to user devices, display devices, Email servers, user telephony
21 devices, CPEs, gateways, routers, user terminals, and/or the like. The hardware
22 database may specify transmission protocols, data formats, and/or the like suitable for
23 communicating with hardware devices employed by any of a variety of IFP BRIDGE affiliated entities. [o o42] In one embodiment, the IFP BRIDGE databases may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. For example, in one implementation, the XML for a Toy Profile in the toys database 246 may take a form similar to the following example:
<Toy> <Quαsi-static info> <Toy_ID>123-45-6789</Toy_ID> <Hσrdwσre_ID> ToyBots_Epet3.0 </Hσrdwσre_ID> <Hσrdwσre_Info> <Circuit_Component0001> <Componnet_Nσme> A3903 </Component_Nσme> <Count> 1 </Count> <Reference> Ul </Reference> <PσtternNσme> DFN8 </PσtternNσme> <Vσlue> A3903 </Vσlue> <Description> Low Voltage DC Motor Driver </Description>
</Ci rcuit_Component0001>
</Hσrdwσre_i nfo> <User_i nfo> <UserNσme> John Smith </UserNσme> <UserAddress> 123 Maple Dr., Smalltown, CA 92676 </UserAddress> <UserPhone> (123)456-7890 </UserPhone> <Email> jsmith@email.com </Email> <UserAccount> ... </UserAccount> <UserSocialMedia> ... </UserSocialMedia> </User_info>
</Quαsi -static info>
<Dynσmic info>
<Applicσtion history>
<Lσst login>
<LoginType> Fσcebook <LoginType>
<Server ID> US-CA-ADD00089 </Server ID>
<Time> 19:33:25 08-30-2009 </Time>
</Lσst login>
</Appli cation history>
</Dynσmic info> </Toy> [OO43] Example hardware sp< one implementation, as shown in Appendices I-IV.
[0044] Figure 3 provides an overview of logic flow illustrating aspects of implementing the IFP BRIDGE with a real-world toy-device and virtual-worlds in one embodiment of the IFP BRIDGE operation. In one embodiment, a user may initialize a real-world toy-device, e.g., through toy configuration and turning on the power, etc., and register the real-world toy-device with the IFP BRIDGE 305, as will be illustrated in Figures 4A-B.
[0045] In one embodiment, the IFP BRIDGE virtual -worlds may instantiate an IFP BRIDGE application 310. For example, in one implementation, an IFP BRIDGE enabled application component, e.g., a video game, etc., may be launched on a user computer. For example, a plug-in of an IFP BRIDGE component may be used to establish the computer to a virtual-world for second life. The IFP BRIDGE may also connect to its own virtual world source, e.g., WooZee's or ToyBot virtual world. In an alternative implementation, an IFP BRIDGE component may be initialized and connected to social media, such as facebook, twitter, MySpace, flickr, and/or the like. [0046] In one embodiment, the IFP BRIDGE may monitor any actions and/or status updates of both the real-world toy-device, and the virtual-worlds 315, and instantiate the real-world-virtual-worlds interactions to synchronize status of the real- world toy-device and a corresponding virtual-world toy-avatar 320, as illustrated in Figures 5A-B. In another embodiment, the IFP BRIDGE may monitor any environment stimuli, e.g., stimuli from another real-world toy-device, environment, 325, and instantiate interactions between two real-world toy-toy interactions, and/or communications between two virtual-world toy-avatars 330, as illustrated in Figures 6A-B.
[0047] Figures 4A-B provide logic flow diagrams illustrating aspects of registering a real-world toy-device with the IFP BRIDGE in one embodiment of the IFP BRIDGE operation. In one embodiment, the real-world toy-device registration may be automatically completed by the toy-device. As shown in Figure 4A, once an IFP BRIDGE real-world toy-device 401 may be instantiated (e.g., powered on) 405, it may automatically query and connect with a virtual-world device 406. For example, in one implementation, the real-world toy-device may query for a computing device 402, such as, but not limited to a laptop, a desktop, a PDA, a smartphone, and/or the like, within a local area network via zero-configuration protocols. The zero-configuration protocols may be any of Service Location Protocol (SLP), Universal Plug and Play (UPnP; e.g., via 1 USB), Jini, Bluetooth Service Discovery Protocol, WS-Discovery, Proprietary Discovery
2 Protocol, Bonjour and/or the like. In an alternative embodiment, the real-world toy-
3 device may directly connect to a virtual-world server via Wi-Fi, 3G networks, and the
4 virtual-world server may receive an indication of registration request 410 from the real-
5 world toy-device 410.
6 [0048] In one implementation, the IFP BRIDGE may prompt the user computing
7 device to download an IFP BRIDGE enabled application component from a virtual-
8 worlds server 403, if such application component is not available on the user computer.
9 [0049] Once a communications channel between the real -world toy-device and
10 the user computing device, the user computing device (computer) 402 may receive a
11 registration request of the real-world toy-device 408, and identifying registration data
12 215, such as hardware identifying information, IP address, MAC address, network
13 acronym, and/or the like. In one implementation, the IFP BRIDGE may generate a toy-
14 avatar by an IFP BRIDGE enabled application component 416. For example, the IFP
15 BRIDGE may query a database based on the received identifying data of the real-world
16 toy-device, and choose a "bear" avatar based on the query result, e.g., the hardware
17 identification of the real-world toy-device may indicate the toy is a "bear." In an
18 alternative implementation, the IFP BRIDGE allows a user to select an avatar for the
19 real-world toy-device.
20 [0050 ] In one implementation, the real-world toy-device and the user computer
21 (virtual-world) may establish a secure communications path and synchronize data 419.
22 In one implementation, information such as profile information, initial device status,
23 hardware configuration, and/or the like may be synchronized. In one implementation, 1 the virtual-world and the real-world toy-device may update an action definition list,
2 which defines each action the real-world toy-device may perceive/receive, and the
3 corresponding responses. For example, in the action definition list, the action "feel
4 squeezed" may be defined as a "Hug," and corresponds to a status update "Hugged:
5 happy" and a responsive action "smile."
6 [0051] Upon the real-world-virtual-world synchronization, the virtual-world may
7 generate a registration entry based on the received toy data 418, and send a registration
8 notification to virtual-worlds servers 420. In one implementation, the virtual-worlds
9 servers may update user accounts with the newly generated real-world toy registration
10 425. For example, in one implementation, the IFP BRIDGE may query a user database
11 based on the registration information (e.g., user information), and associate the real-
12 world toy-device and the generated toy-avatar with the existing user account. In
13 another implementation, the IFP BRIDGE may generate a new user account for the
14 newly registered real-world toy-device. In a further implementation, the IFP BRIDGE
15 may publish a message indicating the new toy via social media, crowd sourcing sites,
16 blog/microblogs, and/or the like.
17 [0052] Figure 4B illustrates an alternative implementation of real-world toy-
18 device registration. In one embodiment, a user may submit a registration request 430
19 to the virtual-world. For example, a user operating a user computer 402 may access an
20 IFP BRIDGE website, and enter to register a new account for a real-world toy-device. In
21 one implementation, the user may enter information with regard to the real-world toy-
22 device 435, including user name, account name, toy-device hardware information, and
23 the virtual-world may generate a registration entry 440 based on the user submitted information, e.g., via web form to an information server/database. In one implementation, the virtual-world may send registration information to virtual-worlds servers 445 and update user account with the real -world toy registration 450 in a similar manner as discussed in Figure 4A. [0053] In one implementation, the real-world toy-device may, or may not participate in the registration described in 430-450. For example, the IFP BRIDGE allows a user to register a real-world toy-device when the device is powered off or not available. In such an implementation, once the real-world toy-device is powered on, a registration notification may be sent to the toy-device 455, and the real-world toy-device may synchronize data with the virtual-worlds 460. [0054] FIGURE 5A provides a logic flow diagram illustrating aspects of the real- world toy-device and the virtual -world interaction in one embodiment of the IFP BRIDGE operation. In one embodiment, the IFP BRIDGE real-world toy-device may monitor status updates 500. As discussed in Figure 2, a toy-device may have a number of interaction/sensors (225a-225g), which may be monitored by the toy-device IFP BRIDGE controller.
[0055] In one embodiment, the real-world toy-device may determine whether it senses any touch 502 (e.g., via sensors, etc.), motion 504 (e.g., via an accelerometer, etc.), location change 505 (e.g., via a GPS receiver, etc.), environment stimuli 506 (e.g., via a thermometer, wireless receivers, etc., as will be further illustrated in Figures 6A-B), and/or the like. If any of 502-506 takes place, the real-world toy-device may generate action data based on the sensor updates 510. The generated action data may be compliant with a pre-determined data format. For example, in one implementation, the 1 generated action data may take a form similar to a binary data packet including fields, as
2 shown in Figure 5C 5002, such as which includes fields such as message type 5005,
3 sequence number 5006 acknowledgement number 5007, data offset 5008, data length
4 5009, checksum 5010, options 5011 and data payload 5012 and/or the like., and/or the
5 like. In one implementation, the data payload may take a form similar to, a 64-byte
6 action type field, including an indication of the sensed action; a 64-byte action source,
7 including an hardware identifier of the sensor; a 64-byte latitude/longitude value for
8 GPS information; and data with variable lengths indicative of characteristics of the
9 action, such as action intensity value, e.g., pressure intensity, light intensity, sound
10 intensity, velocity, and/or the like.
11 [0056] In one implementation, the real-world toy-device may form a query based
12 on the generated action data on an action definition list stored in the real-world toy-
13 device's memory 512 to discern whether the action data is indicated in the action
14 definition list 514. For example, if the generated action data indicated a touch sensor is
15 activated by a user squeezing the toy-device 502, a query on the action definition list
16 may return a match that the "body-queezing" sense reflects that the toy-device has
17 received a hug. The action definition entry of receiving a hug may further indicate
18 responsive actions of the real-world toy-device, for example, the blue LEDs in the eyes
19 of the toy-device are illuminated for 5 seconds, the mouth animatronics generate a
20 smile. In one implementation, the action definition entry of receiving a hug may further
21 indicate a status update "Hugged: Happy," and a communication is sent to a virtual-
22 world server reflecting the updated status information 518, and monitor for feedbacks
23 520. For example, an action-response list may be similar to: Action Response
Hug Giggle
Tummy Poke Tickling Laugh
[0057] An example XML for an example action-response entry may take a form similar to the following example:
<Actionl> <sensor> heσdøøl </sensor> <intensity_min> 50mV </intensity_min> <intensity_mσx> 2000mv </intensity_mσx> <definition> hug </definition> <responsel> <component> mouth_001 </component> <motion> uplift 30 degrees </motion> </responsel> <response2> <component> speσker_001 </component> <motion> articulate giggling sound </motion> </response2>
</Actionl>
[0058] For another example, if the generated action data indicated a touch sensor is activated by some undefined actions, e.g., the real-world toy-device unexpectedly pressed, dropped to the ground, etc., a query on the action definition list may not return any result - e.g., the pressure intensity indicated in the generated data may not match with the definition of a "Hug" in the action definition list. In that case, the real-world toy-device may proceed with monitor the real-world toy status updates 500. For example, as shown in the above XML code, if a head sensor of the toy-device senses pressure intensity outside of a defined range of 5θmV~2θθmV, the action may not be interpreted as a "Hug." [o o 59] In one embodiment, the real-world toy-device may receive a synchronization request 508 from the virtual-worlds. The real-world toy-device may receive and determine the type of the synchronization data 522. In one implementation, the virtual-worlds may synchronize updated action definition list(s) 524 with the real- world toy-device 530. For example, the virtual-worlds may receive an updated action definition list via software upgrade, user submission, and/or the like, and may send the updated action definition list to a real-world toy-device. For example, in one embodiment, the toy-device may run a microserver and send an HTTP(S) post command request for updated behaviors with its device ID. In one implementation, the server will query its driver database based on the device type identification and may similarly send back an updated driver via HTTP(S) post. [O O 6 O ] In one implementation, if the received synchronization data is a segment of new action data (e.g., in the binary data packet format discussed above), the real- world toy-device may proceed with 512. In another implementation, if the received synchronization data indicates virtual-world status update 526, e.g., "Hugged: Happy," etc., the real-world toy-device may proceed with 516 to execute responsive actions as discussed above. In one implementation, the virtual-world status update data may be originated by a virtual-world toy-avatar status update, a message published in the social media, crowd sourcing site, blog/microblog, and/or the like. [ o o 61 ] Figure 5B provides a logic flow diagram illustrating aspects of interactions between virtual-worlds and a real-world toy-device in an alternative embodiment of the IFP BRIDGE operation. As discussed above, in some embodiments, a user may register and/or configure accounts associated with one or more social networking sites, blogs/microblogs, crowdsourcing applications, and/or other virtual-worlds (e.g., a toy- avatar that corresponds to a particular toy-device). In other embodiments, a specified account and/or profile (e.g., toy-avatar profile) may be associated with a particular toy- device and activation and/or registration of the toy-device will cause the account or profile to be instantiated in one or more social network, blog environment, and/or other virtual -world. In some implementations, one or more users may interact with the social networking toy-account, toy-blog/microblog, toy-feed, and/or virtual-world-associated element (toy-avatar). For example, using a computer or PDA/ cell phone, a user may access a social networking site or microblog feed and interact with the toy- account, toy- profile, and/or toy-feed associated with his or her toy-device. For example, twittering "Hug Woozee" to a twitter account associated with the toy-device may get a response from the toy's server virtual avatar after receiving the twitter hug, or may be routed directly to the toy, either of which may parse the action and send back a response 'WooZee miss you," "Woozee hug you too," and/ or the like. [0062] As another example, utilizing a home computer or video game platform, a user may access a virtual-world and interact with a toy-avatar that is associated with a toy-device they have purchased. Similarly, in some embodiments, other users may interact with the toy-accounts, toy-feeds, toy-avatars, and/or the like. In some embodiments, individual toy-avatars may interact with each other. 1 [0063] As shown in Figure 5B, in one embodiment, the virtual-worlds may
2 monitor virtual-world status updates 550. For example, the virtual-world may receive
3 status update by user inputs 552, messages indicating status update from social media
4 554 (including social media, crowd sourcing sites, blog/microblogs etc. associated with
5 an IFP BRIDGE enabled feature), a communication from other virtual-world users/toy-
6 avatars 556, synchronization request from a registered real-world toy-device 558. The
7 virtual-worlds may update the toy/user profile 560 based on the received data if any of
8 552-558 is received. Othereal-worldise, the virtual-worlds may proceed with monitoring
9 550.
10 [0064] In one implementation, the virtual-worlds may update toy/user profile
11 560 based on the received data. For example, in one implementation, if a user submits
12 an indication of action via a user interface 552, e.g., select a "Hug" for a virtual-world
13 toy-avatar, etc., the virtual-world may query a action definition list 561/562, and execute
14 indicated responsive action on the toy-avatar 565. Accordingly, the virtual-worlds may
15 send instructions of responsive actions to the real-world toy-device 566. For example,
16 in one implementation, the virtual-worlds may search for the real-world toy-device on a
17 local area network based on hardware identification of the device. In other
18 implementations, the virtual-worlds may send instructions of status updates and
19 publish a message in social media 567, and/or send status updates to other virtual-
20 world users, e.g., another virtual-world toy-avatar, etc., as illustrated in Figures 6A-B.
21 [ 0065 ] In one implementation, if the virtual-world receives an undefined action
22 indication 562, the virtual-world may notify a user of new action type 563. For example,
23 in one implementation, a user may submit desired action in a descriptive script, such as "Pat," etc., whereby the action "Pat" may not be defined in the action definition list. In one implementation, the IFP BRIDGE virtual-world may provide a user interface for the user to define the action "Pat" and add it to the action definition list. In another implementation, a user may submit a request to add a new action to the virtual-world server.
[0066] The communications between the real-world toy-device and the virtual- world may be supported by a method-call semantics mechnism, e.g., CORBA. For exmaple, in one implementation, the real-world toy-device may run a kernel linux platform (e.g., BusyBox, etc.) to interface an object request borker of a CORBA infrastructure as shown in Figure 5C, and thus invoke a remote object on the virtual- worlds running on a user computer, e.g., each toy-device/toy-avatar is defined as an object. In one implementation, such CORBA mechanism may be used based on various development tools and libraries, e.g., GCC, iPhone SDK, and/or the like.
[0067] For example, the toy-device and the virtual world may define a series of objects, such as, but not limited to accelerometer which may contain information regarding accelerometer status, GPS which may contain information about the device location, pointer which contains information about the user interaction on the screen, screen which contains the screen stream, and/or other data structure which may contain various data streams and constructs pertaining to a given application. In one implementation, the toy-device 5022 as a host may interface with object structure 5025, object Class Structure 5027 running on an object requested broker 5029, and communicate with virtual world 5055 via a network connection 5030. The virtual world may implement a specified object 5050, object skeleton code 5037 running on the target 1 device side object requested broker 5035.
2 [0068] FIGURE 6A-B provide illustrative logic flow diagrams for an embodiment
3 of the ICFP BRIDGE that includes an application and/or component that allows a toy-
4 device to monitor and further interact with environmental stimuli. When the
5 application/component is activated, the toy-device sensors monitor for stimuli 6002. In
6 some embodiments, the relevant stimuli may be general categories of stimuli (e.g.,
7 music, loud noises, light, voices, etc.), while in other embodiments the stimuli of interest
8 may be indicated (e.g., specific sounds, pictures, faces (via camera and image
9 recognition software), television transmissions (shows and/or advertisements), etc.). If
10 stimuli is monitored by the sensors 6004, it is evaluated to determine if one or more
11 actions are indicated 6006. Depending on the embodiment, this determination may be
12 made by the toy-device, while in another embodiment, the determination may be made
13 at a server in communication with the toy-device. If one or more actions are indicated
14 6008, the toy-device (and/or associated processor(s)) execute the indicated action(s)
15 6010. For example, in one embodiment, the toy-device may have one or more sensors
16 configured to monitor for a signal or sound associated with an advertisement or
17 program (e.g., television, radio, etc.). When the toy-device sensors receive 6002 and
18 identify 506 the signal or sound, instructions stored in the toy device (and/or at a
19 remote server) may cause the toy device to react, for example: dance, act out a scene,
20 recite dialog, and/or the like.
21 [0069] This type of response may also be derived via the action definition list, but
22 in addition to obtaining data from sensors, an interpreted input may be utilized, e.g., if a
23 friend is recognized via stimuli, if owner results in an cheerful giggling by the toy, 1 and/or if there has been a time away from the toy, and/or the like. In one
2 implementation, there may be timing supports to activate motors/peripherals. For
3 example, the toy-device may control an arm motor to wave up and down within 30
4 degrees for 10 seconds, a speaker to articulate giggling sound for 5 seconds, and/or the
5 like. In one implementation, these action paramters themselves may reference as
6 function calls with the parameters being sent to the peripheral devices for actuation.
7 [0070] In some embodiments, the environmental stimuli monitoring may include
8 monitoring for the presence of other toy-devices. FIGURE 6B provides an illustrative
9 flow diagram for one embodiment in which a toy-device has presence monitoring
10 enabled. In such an embodiment, the toy-device monitors for the presence of other toy-
11 devices 602, for example, using Bluetooth, wifi, infrared, and/or the like. If another toy-
12 device is detected 604, a communication application may be engaged/activated 608 to
13 establish communication with the other toy-device. If communication is established
14 610, the toy-device may request an ID (and/or like indicia, security tokens, etc.) from
15 the other toy-device 612. When the other toy-device's ID is received 614, it is
16 evaluated/verified 616. In some embodiment, the verification can be confirmation that
17 toy-device ID is from a toy-device in a "trusted" or "approved" list. In some
18 embodiments, trusted toy-devices may be identified based on social network
19 relationships (e.g.,if a toy-device is a contact on a social network, it is trusted).
20 Additionally or alternatively, a user may be prompted to specify whether a certain toy-
21 device is trusted.
22 [0071] If it is determined that the toy-device is not trusted 618, that particular
23 toy-device may be excluded from monitoring 620 (e.g., further communication is disabled). If it is determined that the toy-device is trusted 618, communication and interaction is enabled, and the toy-devices can communicate and interact 622. If a communication is received from a trusted toy-device 624, and an action is indicated 626, the action is then executed 628 (as discussed in detail above). In some embodiments, different levels of trust or access may be specified, and as such, may limit or otherwise specify permitted/ disallowed actions/instructions. In some implementations, the presence/monitoring for other toy-devices may be tunable/ sharable, such that parameters govern the identification and interaction between toy-devices. In some embodiments, the communication/coordination between toy-devices may allow two or more toy-devices to act out a movie scene (and particular, when combined with the features discussed in FIGURE 5, act out a movie scene when the scene is playing on a television or the like), have a dialogue, coordinate dance moves, etc. For example, a toy-device may be identified by another toy-device as authorized, and recognize its device type. The other toy-device may then send an action either directly or via virtual-world bridge to the first toy-device, and then the other toy-device may interpret and react to the received action.
[0072] In one embodiment, real-world toy-device applications may be written as widgets, for example, in JavaScript and executed by the toy-device's on-board web server. In another embodiment, an online store allows for the aggregation and selling of various real-world toy widget applications that may be purchased and then downloaded to a user's real-world toy-device associated with their profile/account. In one embodiment, these widget can make use of underlying applications called Behaviors. Behaviors may themselves be applications that drive underlying real-world toy-device sensors and/or actuators. For example, a behavior may be to blink, where a toy-device's servos are actuated to move toy eyes opened and closed. As such, applications may build upon abstracted behaviors to various real-world toy-device implementations. As such, applications may make use of real-world on-board sensors to generate contextualized behavior. For example, when the real-world toy-device has a camera to detect proximity of strangers in addition to the real-world toy-device's handler, a GPS sensor will inform the toy to say "Bonjour" when in France, and "HoIa" when in Spain.
[o o 73] Figures 7A-C provide example screen shots illustrating aspects of different implementations of the IFP BRIDGE operation. In one embodiment, the ICFP BRIDGE may make applications/services available for implementation on a toy-device, toy- account/profile, and/or toy-avatar. Some of these applications/services utilize records and/or profiles associated with toy-devices. For example, as shown in Figure 7 A, a toy- device may implement a to "story-time" application that allows a user on a social networking site or in a virtual-world to talk to or provide an audio file to a toy-avatar. This interaction may be stored (e.g., a recording of what was said by the user is made and stored in a database, or the audio file is similarly stored) and may be subsequently transmitted to and stored by the toy-device via data synchronization 707 between the real-world toy-device and the virtual-worlds. In some embodiments, a user of the toy- device may be able to activate playback of the recording at any time after the toy-device has received and stored it 701. For example, the playback may be activated by a user touching and/or hugging the real-world toy-device 705, and/ or articulate "Tell Story" as the real-world toy-device may analyze the user speech and translate into a command to playback the story. 1 [o o 74] In an alternative implementation, a user may configure the story playback
2 to occur at a user-determined time. For example, a user's friends/family may record a
3 greeting message "happy birthday" via a social networking site, and set the time for an
4 associated real-world toy-device to play the message at 12 AM of the user's birthday. In
5 one implementation, the real-world toy-device may receive and perform such
6 commands to playback a "happy birthday" message (e.g., via LCD display, microphone
7 speaker, etc.) at the pre-determined time. For example, the toy-device may control a
8 speaker to articulate a pre-recorded "happy birthday" audio.
9 [0075] In one embodiment, the toy-device may be a display output of the toy,
10 which itself may run on Android, Linux, where all the sensors and toy animatronics are
11 peripheral devices actuated and accessed through device drivers.
12 [0076] In a further embodiment, a user's reaction to/subsequent interaction with
13 the toy device may be monitored and/or recorded. As shown in Figure 7B, for example,
14 a user of a social media may send an audio message to the toy-account of another user
15 715 via the social networking site (e.g., a grandmother sends a message to her
16 grandson). The toy-device may subsequently play the audio message, and record the toy
17 device user's response to the message (e.g., via a video/audio recorder and/or other
18 sensors). This recorded/monitored response may then be saved locally, transmitted to
19 server for storage, and/or transmitted to the sending user (e.g., grandmother), for
20 example, via a social networking website, email, and/or the like. In one embodiment,
21 these messages may be staged, stared and redirected from the virtual-world server.
22 They may be experience within the virtual world, or redirected to the targets'
23 email/social/media addresses. Similarly, general responses from the user of the toy- device, such as laughing, squeezing of the toy device, etc., may be monitored by the toy- device, evaluated, and an associated account/profile and/or feed may be updated to reflect this interaction (e.g., "is happy", "is laughing", "is being hugged", etc.). [0077] In one embodiment, the toy may be interacted with and the virtual-world toy avatar may reflect and respond to actions on the toy. For example, hugging the toy- device would cause a virtual-world avatar an action of hugging. For another embodiment, the virtual-world may be displayed right on the toy-device's LCD screen. Alternatively, in one embodiment, the toy may be used as a game controller to cause movement of a virtual-world avatar, as further illustrated in Figure 7C. [0078] In some embodiments, accessing an application, such as a story-time application, may require that there be one or more changes or events, as indicated by the internal record. For example, in one implementation, activating the toy-device playback element of the story-time application may require that the toy-device internal record indicate that the toy-device has been hugged at least twice within the last hour, that the toy-device is in a designated location (e.g., the home of the owner/user, as indicated by a GPS or like component), that the toy-device is currently being held (as indicated by a touch sensor), and that the local time is after 7 pm. If all of these conditions are met, the toy-device then plays the most recent recording stored by the story-time application. Playback may include audio playback as well as animatronics and/or other features of the toy-device. Other applications may include coordinated movements (e.g., dancing, fighting, etc.) between two or more toy-devices, as discussed in greater detail regarding Figures 7A-B. Such interactions may require that additional preconditions be met before being carried out, for example, that the toy devices are 1 within a specified proximity of one another, that the toy-devices be linked via social
2 networking accounts (e.g.,the toy-profiles indicate friendship or other connection), etc.
3 [0079] Other applications/services may similarly affect the toy-account/profile
4 and/or toy-avatar in the virtual-world, or may affect both the toy-device and the
5 associated accounts atoy-avatar. For example, a toy-health application may have one or
6 more metrics (e.g.,health metrics) that decay over time (e.g., 10% per day) unless
7 virtual-world (e.g., the toy-avatar is fed in the virtual-world) and/or real-world (the toy-
8 device registers touches or hugs in the real-world) interaction is registered. In one
9 embodiment, the toy-device may have a mouth sensor that monitors for input, such as
10 feeding (e.g., via a corresponding spoon or bottle device that interacts with the mouth
11 sensor to indicate "feeding" or "eating"). The metrics may influence abilities,
12 appearances and/or other characteristics of the toy-device, toy-account/profile, and/or
13 toy-avatar. For example, if the health metrics drop below 50% of normal, the toy-
14 account may indicate "hungry", an associated feed may indicate "feed me", the toy-
15 avatar may wither in the virtual-world, and/or the toy-device may appear to be unhappy
16 (e.g., animatronics may make the toy-device frown).
17 [0080] In an alternative embodiment, the IFP BRIDGE may allow a user to use
18 the real-world toy-device as a game controller to play a video game characterized by the
19 corresponding virtual -world toy-avatar in real time. As shown in Figure 7C, a user may
20 launch an IFP BRIDGE enabled video game application 750, and enter a gaming session
21 751. In one implementation, the user may select "real-world toy control" to play the
22 game, and then connect the real-world toy-device with the virtual-world (e.g., a
23 computer running the video game, etc.). For example, as shown in 752-754, in one implementation, a user may move/ elevate a real-world toy-device 752 in a manner that the toy is jumping over a curdle. The movement of the real-world toy-device may be transmitted to the virtual-worlds in real time, and is reflected in the virtual-worlds as the toy-avatar may jump over a hurdle shown in the video game. Patent Cooperation Treaty Application No. PCT/USio/23961, filed February 11, 2010, entitled "APPARATUSES, METHODS AND SYSTEMS FOR AN INTERACTIVE PROXIMITY DISPLAY TETHER WITH REMOTE CO-PLAY, is incorporated herein by reference. [0081] FIGURES 8A-C provide details on toy-devices and virtual-world (including social network, feed, blog/microblog, etc.) interactions for some embodiments of the IFP BRIDGE. Figure 8A illustrates aspects of the structure of a toy- device, including a bear-shaped body, with embedded GPS/WiFi/βG receivers 808, animatronics 805 (e.g. to facilitate eyes, mouth, cheek movement to create facial expressions), speaker/microphone 806, flash memory 820, LCD display 801, and/or the like. In one implementation, the toy-device may have touch sensors on the head, back and the arms 815. For example, in one implementation, 815 may employ a Phidgets 1110 touch sensor, provides a voltage measure of proximity and pressure. This may be used to detect and interpret proximity/pressure content, as discussed in Figure 6A-B. [0082] Figure 8B provides details about virtual-world and social network aspects of a particular implementation of the IFP BRIDGE. For example, the IFP BRIDGE may facilitate a user to configure feed options, settings, friend options, games, status updates, newsfeed, shopping preferences in various applications in social media and networks. In another implementation, the toy-device may be associated with human emulated attributes such as age, health, happiness, hunger, unique IDs, energy, mood 1 and/or the like. Other implementations of the ICFP BRIDGE may include, but are not
2 limited to, toy-devices configured as guns or other weapons or tools that allow for
3 interworld play between the real-world and a virtual-world.
4 Replaceable IFP BRIDGE real-world Toy-Device
5 [0083] Figure 9 provides an overview diagram illustrating an IFP BRIDGE real-
6 world toy-device with replaceable animatronics in one embodiment of the IFP BRIDGE
7 operation. As shown in Figure 9, a real-world toy-device may have a toy-shaped "body-
8 shell" with chambers to plug removable plugged-in animatronics, memory cards, micro-
9 motors, processor main board, and/or the like. For example, the real-world toy-device
10 body-shell may have a core controller chamber 905 to place a processor controller 950
11 (as further illustrated in Figures 10A-J), central motor, etc.; a storage device chamber
12 906 to plug in a USB jumbo drive, a flash memory card, and/or the like; a GPS chamber
13 9io(f) to plug in a GPS receiver; a receptacle 9io(e) placed in the abdomen area of the
14 toy body-shell to attach a removable LCD screen; a microphone speaker chamber
15 9io(b) to plug in a removable microphone speaker; a LED animatronics chamber
16 9io(c); a wireless receiver chamber 9io(a) for Wi-Fi, Bluetooth antenna, etc. In one
17 implementation, the removable components may be docked into the chamber via USB
18 connection, 30 pin docking connector, and/or the like. In one embodiment, an Android
19 Nexus One, iPod Touch, iPhone, and/or the like may be plugged into the LCD display
20 chamber via a 30-pin, (micro) USB 955, dock connector, etc., and download
21 applications, and perform as the toy-device controller.
22 [0084] In one embodiment, the replaceable real-world toy-device may allow a
23 user to change an appearance of a real-world toy-device. For example, in one implementation, if a user may change a toy-avatar in the virtual-worlds from a "bear" to a "rabbit," the user may desire to change the appearance of the real-world toy-device as well. Instead of obtaining/purchasing, and re-registering a new real-world toy-device with a "rabbit" look, the user may obtain/purchase a "rabbit" body-shell, which may be more cost-efficient, and fill in the "rabbit" body-shell with electronic components from the "bear" body-shell. In that case, the IFP BRIDGE allows an appearance change of the real-world toy-device without any re-registration. [0085] For another example, if malfunctions occur with one or more of the animatronics of the real-world toy-device (e.g., LED broken, LCD display scratched, etc.), a user may purchase a new plug-in component to replace the malfunctioned ones, instead of purchasing a new toy. In one implementation, if a new component (e.g., new LED animatronics, a new LCD display, etc.) may be docked into the body-shell, the IFP BRIDGE controller may automatically detect and recognize the new component, e.g., based on the hardware identifier, etc., and modify driver addresses to map to the newly connected component accordingly. [0086] Figures 10A-J provide example circuit configurations of a toy-device controller in one implementation of the IFP BRIDGE. For example, in one implementation, the hardware specification of components in Figures 10A-J may include and take the form similar to the following component listing:
Count ComponentNσme RefDes PσtternNσme Value Description
Integ rated Ci rcuits
1 A3903 U20 DFN8 A3903 Low Voltqge DC Motor Driver
1 AT45DB642D U3 CAS0NAT45DB642D 64-megσbit 2.7-volt Only
Dual-interface DataFlash AT45DB642 (Nl (Nl (Nl (Nl (Nl
1 AT91RM9200 Ul F-QFP28X28-G208/Y1.35N1EST 32 bit ARM based microcontroller
1 CP2102 U5 28 pin QFN Highly-integrated USB-to-UART Bridge Controller
DS9503 U7.U18 6_LD_TS0C ESD protection device for 1- Wi re interfaces
1 FV-4A UIl FV-4A_FB FV-4A GPS onboard
1 G20 U12 G20 Cellular wireless module
1 LP3982 LLP U13 LLP8LP3982 LLP 1V8 Low-dropout (LDO) CMOS linear regulator
4 LP3982 LLP U10 LLP8LP3982 LLP 3V3 Low-dropout (LDO) CMOS linear regulator
1 MAX9788_TQFN U6 MAX9788 Mono Class G power amplifier (speaker driver)
1 MC9S08QE32_QFN48 U19 QFN7X7-48 8 bit microcontroller for user interface control
1 MCP7381X U14 S0T23-5MCP73811 Fully integrated linear charge management controller (battery charger)
1 MMA7660 U21 MMA7660MMA7260Q Digital output accelerometer with motion detection
1 MPR084 U9 TSS0P16 Inter-Integrated Circuit Communication (I2C) driven Capacitive Touch Sensor Controller
1 MT29F2G16AADWP U8 TS0P48 IC NAND FLASH 2GB 3.3V 48-TSOP
1 MT48LC16M16A2TG-7E U2 TS0P2-54 256Mb DRAM memory P11961-ND MIC MICl MIC MICROPHONE OMNI 6X1.3MM
1 TLV320AIC23BIPW U23 SS0P28 IC STEREO AUDIO CODEC 28-TSSOP TPA4861 U25.U30 S08TPA4861 1-W Mono Audio Power Amplifier
Connectors
IDC1X4M J20.J21 IDC1X4M Ibuttons & programming connector
IDC2X4 J13.J24 IDC2X4 External buttons connector
1 IDC2X5M J9 IDC2X5MJTAG Jtag connector
1 M0LEX2PINS J25 M0LEX2PINS BATTERY Battery connector
1 M0LEX2PINS J26 M0LEX2PINS MOTOR Motor Output connector
1 M0LEX2PINS J27 M0LEX2PINS SPEAKER Speaker connector
(Nl (Nl (Nl (Nl (Nl
M0LEX2PINS J23 M0LEX2PINSSPK L Speaker connector
M0LEX2PINS J22 M0LEX2PINSSPK R Speaker connector
M0LEX3PINS J12 M0LEX3PINSEYES Eyes input connector
M0LEX3PINS J14 M0LEX3PINS MOUTH Mouth input connector
M0LEX3PINS J15 M0LEX3PINSUART DEBUG debug uart connector
M0LEX5PINS J304 M0LEX5PINS LEDS&BUTTON LEDs & buttons connector
1 M0LEX5PINS J302 M0LEX5PINS USB connector
1 PH0ENIX2S0R CONl C0N2PH0ENIXS0RGPS ANTENNA GPS ANTENNA connector
1 SIMSD_670-1522-1-ND J3 SIMSDDUAL Dual CONN MICRO SD/SIM MEMORY SMD
Passive components
CAP0603 C20 6031N5 Capacitor
7 CAP0603 C18 603IuF Capacitor
6 CAP0603 C155 6032.2uF Capacitor
1 CAP0603 C117 6034n7 Capacitor
1 CAP0603 C124 6035n6 Capacitor
3 CAP0603 C21 6038p2 Capacitor
3 CAP0603 C74 60310pF Capacitor
CAP0603 C128 60312.5pF Capacitor
CAP0603 C126 60318pF Capacitor
3 CAP0603 C22 60327pF Capacitor
5 CAP0603 C143 60333nF Capacitor
1 CAP0603 C153 60333pF Capacitor
CAP0603 C72 60347pF Capacitor
68 CAP0603 C8 603100nF Capacitor
4 CAP0603 C70 603470nF Capacitor
1 CAP0603 C122 603470pF Capacitor
1 CAP0603 C123 603680pF Capacitor
CAP1206P C139 1206P4.7uF Capacitor
14 CAP1206P C26 1206P10uF Capacitor
8 CAP1206P C131 1206P47uF Capacitor
(Nl (Nl (Nl (Nl (Nl (Nl (Nl (Nl
1 CAPELNA1000 C2 CAPELNA1000220uF Capacitor
1 CAPELNA1000 Cl CAPELNA10001000UF Capacitor
8 RES0603 R32 6030R Resistor
3 RES0603 R59 603 IK Resistor
1 RES0603 R103 6031K27 1% Resistor
1 RES0603 R102 6031K96 1% Resistor
RES0603 R30 6033K3 Resistor
RES0603 R22 6034K7 Resistor
5 RES0603 R36 6034K99 Resistor
1 RES0603 R119 6035R6 Resistor
19 RES0603 R37 60310K Resistor
RES0603 R19 60312K Resistor
RES0603 R26 60322k Resistor
RES0603 R15 60324K3 Resistor
RES0603 R70 60332 Resistor
6 RES0603 R25 60347k Resistor
1 RES0603 R40 60356R Resistor
7 RES0603 R38 603100 Resistor
14 RES0603 R17 603100k Resistor
RES0603 R16 603220K Resistor
6 RES0603 R29 603470R Resistor
2 RES0603 R112 603680R Resistor
8 RES0603 R46 603780K Resistor
RES0603 R39 603 DNP Resistor
4 RES0603 R71 603 NPI Resistor
1 RES0603 R123 603 R0 Resistor
1 XTALT38 X101 T3832768HzXTAL Oscillator
1 DS321G X100 XTALDSX321G 18.432Mhz XTAL Oscillator
7 IND0805 FBI 805Ferrite ferrite beds
3 DZS0T23 DZl S0T-23(AlA2K) 3v3 Zener diodes 4 FDN360P U15,U17,U26,U28S0T-23(BEC)FDN360P P-chσnnel mosfet 4 LED1206 DLl 1206K {Value} SMD LEDs
5 NPNS0T23 Q3 S0T-23(BEC) BC846 NPN transistor
1 P0LYSW_RXE050 Fl CAP200500mA Polyswitch Count ComponentNameRefDes PatternName Value Description
Integrated Circuits
A3903 Ul DFN8 A3903 Low Voltqge DC Motor Driver
DS9503 U76_LD_TS0C ESD protection device for 1-Wire interfaces
LP3982 LLP U5 LLP8 LP3982 LLP 3V3 Low-dropout (LDO) CMOS linear regulator
MC9S08QE128_LQFP64 U10F-QFP10X10-G64_P.5N 8 bit microcontroller for user interfase control
MCP7381X U14S0T23-5MCP73811 Fully integrated linear charge management controller (battery charger)
MMA7660 U21MMA7660MMA7260Q Digital output accelerometer with motion detection
MPR084 U9TSS0P16 Inter-Integrated Circuit Communication (I2C) driven Capacitive Touch Sensor Controller
Connectors
1 IDC1X4M J6 IDC1X4M TOUCH 1 IDC2X3M 37 IDC2X3MAUX 1 IDC2X3M J 10 IDC2X3MBDM 1 IDC2X4 J8 IDC2X4BUTT 1 IDC2X4 J9 IDC2X4MPR_BUT 1 M0LEX2PINS J5 M0LEX2PINS BATTERY Battery connector 1 M0LEX2PINS J3 M0LEX2PINS MOTORl Motor Output connector 1 M0LEX2PINS J4 M0LEX2PINS M0T0R2 Speaker connector 1 M0LEX2PINS J12 M0LEX2PINS SPK L Speaker connector 1 M0LEX2PINS JIl M0LEX2PINS SPK R Speaker connector 1 M0LEX2PINS J13 M0LEX2PINS SPK_G24 Eyes input connector 1 M0LEX3PINS Jl M0LEX3PINS EYES Mouth input connector 1 M0LEX3PINS J2 M0LEX3PINS MOUTH debug uart connector
(Nl (Nl (Nl (Nl (Nl (Nl
1 M0LEX5PINS J14 M0LEX5PINS LEDS&BUTTON LEDs & buttons connector
4 AMP252155 CONl AMPHEN0L252155 DIGI ACX1453-ND RF Connector
1 FX2-32P-1.27DS(71) P1HIROSE-32P-1.27DS(71) DIGI H10629-ND Boσrdmount
PPiin Connector
Passive components
4 CAP0603 C5 603IuF Capacitor
1 CAP0603 C10 60333nF Capacitor
10 CAP0603 C7 603100nF Capacitor CAP1206P C3 1206P10uF Capacitor CAP1206P Cl 1206P47uF Capacitor
RES0603 R32 6030R Resistor
RES0603 R59 603 IK Resistor
RES0603 R30 6033K3 Resistor
11 RES0603 R22 6034K7 Resistor
5 RES0603 R37 60310K Resistor
2 RES0603 R26 60322k Resistor
4 RES0603 R25 60347k Resistor
1 RES0603 R38 603100 Resistor
4 RES0603 R17 603100k Resistor
6 RES0603 R29 603470R Resistor
8 RES0603 R46 603780K Resistor
3 DZS0T23 DZl S0T-23(AlA2K) 3v3 P-channel mosfet
FDN360P U3 S0T-23(BEC) FDN360P SMD LEDs
4 LED1206 DLl 1206K {Value} NPN transistor
4 NPNS0T23 Q3 S0T-23(BEC)BC846 Polyswitch
1 P0LYSW_RXE050 Fl CAP200500mA
1 PUSHBUTTON SWl PUSHBUTTONNA DNP Power Button IFP BRIDGE Controller [0087] FIGURE 11 illustrates inventive aspects of a IFP BRIDGE controller 1101 in a block diagram. In this embodiment, the IFP BRIDGE controller 1101 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through wireless transmission and data synchronization technologies, and/or other related data.
[0088] Typically, users, which may be people and/or other systems, may engage information technology systems (e.g., computers) to facilitate information processing. In turn, computers employ processors to process information; such processors 1103 may be referred to as central processing units (CPU). One form of processor is referred to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory 1129 (e.g., registers, cache memory, random access memory, etc.). Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations. These stored instruction codes, e.g., programs, may engage the CPU circuit components and other motherboard and/or system components to perform desired operations. One type of program is a computer operating system, which, may be executed by CPU on a computer; the operating system enables and facilitates users to access and operate computer information technology and resources. Some resources that may be employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed. These information technology systems may be used to collect data for later retrieval, analysis, and manipulation, which may be facilitated through a database program. These information technology systems provide interfaces that allow users to access and operate various system components.
[0089] In one embodiment, the IFP BRIDGE controller 1101 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 1111; peripheral devices 1112; an optional cryptographic processor device 1128; and/or a communications network 1113. [0090] Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term "server" as used throughout this application refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting "clients." The term "client" as used herein refers generally to a computer, program, other device, user and/or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network. A computer, other device, program, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a "node." Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked 1 with furthering the passage of information from a source to a destination is commonly
2 called a "router." There are many forms of networks such as Local Area Networks
3 (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc.
4 For example, the Internet is generally accepted as being an interconnection of a
5 multitude of networks whereby remote clients and servers may access and interoperate
6 with one another.
7 [0091] The IFP BRIDGE controller 1101 may be based on computer systems that
8 may comprise, but are not limited to, components such as: a computer systemization
9 1102 connected to memory 1129.
10 Computer Systemization
11 [0092] A computer systemization 1102 may comprise a clock 1130, central
12 processing unit ("CPU(s)" and/or "processor(s)" (these terms are used interchangeable
13 throughout the disclosure unless noted to the contrary)) 1103, a memory 1129 (e.g., a
14 read only memory (ROM) 1106, a random access memory (RAM) 1105, etc.), and/or an
15 interface bus 1107, and most frequently, although not necessarily, are all interconnected
16 and/or communicating through a system bus 1104 on one or more (mother)board(s)
17 1102 having conductive and/or othereal-worldise transportive circuit pathways through
18 which instructions (e.g., binary encoded signals) may travel to effect communications,
19 operations, storage, etc. Optionally, the computer systemization may be connected to an
20 internal power source 1186. Optionally, a cryptographic processor 1126 may be
21 connected to the system bus. The system clock typically has a crystal oscillator and
22 generates a base signal through the computer systemization's circuit pathways. The
23 clock is typically coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of instructions embodying information throughout a computer systemization may be commonly referred to as communications. These communicative instructions may further be transmitted, received, and the cause of return and/or reply communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems.
[0093] The CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. Often, the processors themselves will incorporate various specialized processing units, such as, but not limited to: integrated system (bus) controllers, memory management control units, floating point units, and even specialized processing sub-units like graphics processing units, digital signal processing units, and/or the like. Additionally, processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 529 beyond the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a memory address space that is accessible via instruction address, which the processor can construct and decode allowing it to access a circuit path to a specific memory address space having a memory state. The CPU may be a microprocessor such as: AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic and/or optic circuits) to execute stored instructions (e.g.,program code) according to conventional data processing techniques. Such instruction passing facilitates communication within the IFP BRIDGE controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed IFP BRIDGE), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed.Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed. [0094] Depending on the particular implementation, features of the IFP BRIDGE may be achieved by implementing a microcontroller such as CAST'S R8051XC2 microcontroller; Intel's MCS 51 (e.g., 8051 microcontroller); and/or the like. Also, to implement certain features of the IFP BRIDGE, some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit ("ASIC"), Digital Signal Processing ("DSP"), Field Programmable Gate Array ("FPGA"), and/or the like embedded technology. For example, any of the IFP BRIDGE component collection (distributed or othereal-worldise) and/or features may be implemented via the microprocessor and/or via embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of the IFP BRIDGE may be implemented with embedded components that are configured and used to achieve a variety of features or signal processing. [0095] Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/ software solutions. For example, IFP BRIDGE features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the IFP BRIDGE features. A hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the IFP BRIDGE system designer/administrator, somewhat like a one-chip programmable breadboard. An FPGA's logic blocks can be programmed to perform the function of basic logic gates such as AND, and XOR, or more complex combinational functions such as decoders or simple mathematical functions. In most FPGAs, the logic blocks also include memory elements, which may be simple flip-flops or more complete blocks of memory. In some circumstances, the IFP BRIDGE may be developed on regular FPGAs and then migrated into a fixed version that more resembles ASIC implementations. Alternate or coordinating implementations may migrate IFP BRIDGE controller features to a final ASIC instead of or in addition to FPGAs. Depending on the implementation all of the aforementioned embedded components and microprocessors may be considered the "CPU" and/or "processor" for the IFP BRIDGE. Power Source [0096] The power source 1186 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy. The power cell 1186 is connected to at least one of the interconnected subsequent components of the IFP BRIDGE thereby providing an electric current to all subsequent components. In one example, the power source 1186 is connected to the system bus component 1104. In an alternative embodiment, an outside power source 1186 is provided through a connection across the I/O 1108 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power.
Interface Adapters [0097] Interface bus(ses) 1107 may accept, connect, and/or communicate to a number of interface adapters, conventionally although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) 1108, storage interfaces 1109, network interfaces 1110, and/or the like. Optionally, cryptographic processor interfaces 1127 similarly may be connected to the interface bus. The interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters conventionally connect to the interface bus via a slot architecture. Conventional slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.
[0098] Storage interfaces 1109 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 1114, removable disc devices, and/or the like. Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
[0099] Network interfaces 1110 may accept, communicate, and/or connect to a communications network 1113. Through a communications network 1113, the IFP BRIDGE controller is accessible through remote clients 1133b (e.g., computers with web browsers) by users 1133a. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 8θ2.na-x, and/or the like. Should processing requirements dictate a greater amount speed and/or capacity, distributed network controllers (e.g., Distributed IFP BRIDGE), architectures may similarly be employed to pool, load balance, and/or othereal-worldise increase the communicative bandwidth required by the IFP BRIDGE controller. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. A network interface may be regarded as a specialized form of an input output interface. Further, multiple network interfaces mo may be used to engage with various communications network types 1113. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks.
[00100] Input Output interfaces (I/O) 1108 may accept, communicate, and/or connect to user input devices 1111, peripheral devices 1112, cryptographic processor devices 1128, and/or the like. I/O may employ connection protocols such as, but not limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus (ADB), IEEE I394a-b, serial, universal serial bus (USB); infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface: Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless: 802.na/b/g/n/x, Bluetooth, code division multiple access (CDMA), global system for mobile communications (GSM), WiMax, etc.; and/or the like. One typical output device may include a video display, which typically comprises a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may be used. The video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Another output device is a television set, which accepts signals 1 from a video interface. Typically, the video interface provides the composited video
2 information through a video connection interface that accepts a video display interface
3 (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI
4 connector accepting a DVI display cable, etc.).
5 [o o io i] User input devices mi may be card readers, dongles, finger print readers,
6 gloves, graphics tablets, joysticks, keyboards, mouse (mice), remote controls, retina
7 readers, trackballs, trackpads, and/or the like.
8 [00102] Peripheral devices 1112 may be connected and/or communicate to I/O
9 and/or other facilities of the like such as network interfaces, storage interfaces, and/or
10 the like. Peripheral devices may be audio devices, cameras, dongles (e.g., for copy
11 protection, ensuring secure transactions with a digital signature, and/or the like),
12 external processors (for added functionality), goggles, microphones, monitors, network
13 interfaces, printers, scanners, storage devices, video devices, video sources, visors,
14 and/or the like.
i5 [o o iO3] It should be noted that although user input devices and peripheral devices
16 may be employed, the IFP BRIDGE controller may be embodied as an embedded,
17 dedicated, and/or monitor-less (e.g., headless) device, wherein access would be provided
18 over a network interface connection.
19 [00104] Cryptographic units such as, but not limited to, microcontrollers,
20 processors 1126, interfaces 1127, and/or devices 1128 may be attached, and/or
21 communicate with the IFP BRIDGE controller. A MC68HC16 microcontroller,
22 manufactured by Motorola Inc., may be used for and/or within cryptographic units. The
23 MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the i6 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation. Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions. Cryptographic units may also be configured as part of CPU. Equivalent microcontrollers and/or processors may also be used. Other commercially available specialized cryptographic processors include: the Broadcom's CryptoNetX and other Security Processors; nCipher's nShield, SafeNet's Luna PCI (e.g., 7100) series; Semaphore Communications' 40 MHz Roadrunner 184; Sun's Cryptographic Accelerators (e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); Via Nano Processor (e.g., L2100, L2200, U2400) line, which is capable of performing 500+ MB/s of cryptographic instructions; VLSI Technology's 33 MHz 6868; and/or the like.
Memory [00105] Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory 1129. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another. It is to be understood that the IFP BRIDGE controller and/or a computer systemization may employ various forms of memory 1129. For example, a computer systemization may be configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage devices are provided by a paper punch tape or paper punch card mechanism; of course such an embodiment would result in an extremely slow rate of operation. In a typical configuration, memory 1129 will include ROM 1106, RAM 1105, and a storage device 1114. A storage device 1114 may be any conventional computer system storage. Storage devices may include a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (e.g.,Blueray, CD ROM/RAM/Recordable (R)/ReWritable (real-world), DVD R/real-world, HD DVD R/real-world etc.); an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable storage mediums; and/or other devices of the like. Thus, a computer systemization generally requires and makes use of memory.
Component Collection [00106] The memory 1129 may contain a collection of program and/or database components and/or data such as, but not limited to: operating system component(s) 1115 (operating system); information server component(s) 1116 (information server); user interface component(s) 1117 (user interface); Web browser component(s) 1118 (Web browser); database(s) 1119; mail server component(s) 1121; mail client component(s) 1122; cryptographic server component(s) 1120 (cryptographic server); the IFP BRIDGE component(s) 1135; and/or the like (e.g., collectively a component collection). These components may be stored and accessed from the storage devices and/or from storage devices accessible through an interface bus. Although non- conventional program components such as those in the component collection, typically, are stored in a local storage device 1114, they may also be loaded and/or stored in memory such as: peripheral devices, RAM, remote storage facilities through a communications network, ROM, various forms of memory, and/or the like. Operating System [00107] The operating system component 1115 is an executable program component facilitating the operation of the IFP BRIDGE controller. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/ or the like. The operating system may be a highly fault tolerant, scalable, and secure system such as: Apple Macintosh OS X (Server); AT&T Plan 9; Be OS; Unix and Unix-like system distributions (such as AT&T's UNIX; Berkley Software Distribution (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating systems. However, more limited and/or less secure operating systems also may be employed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 2OOO/2OO3/3.i/95/98/CE/Millenium/NT/Vista/XP (Server), Palm OS, and/or the like. An operating system may communicate to and/or with other components in a component collection, including itself, and/or the like. Most frequently, the operating system communicates with other program components, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program components, memory, user input devices, and/or the like. The operating system may provide communications protocols that allow the IFP BRIDGE controller to communicate with other entities through a communications network 1113. Various communication protocols may be used by the IFP BRIDGE controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/ or the like.
Information Server [00108] An information server component 1116 is a stored program component that is executed by a CPU. The information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the like. The information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (e.g., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components. After a Domain Name System (DNS) resolution portion of an HTTP request is resolved to a particular information server, the information server resolves requests for information at specified locations on the IFP BRIDGE controller based on the remainder of the HTTP request. For example, a request such as http://123.124.125.126/mylnformation.html might have the IP portion of the request "123.124.125.126" resolved by a DNS server to an information server at that IP address; that information server might in turn further parse the http request for the "/mylnformation.html" portion of the request and resolve it to a location in memory containing the information "mylnformation.html." Additionally, other information serving protocols may be employed across various ports, e.g., FTP communications across port 21, and/or the like. An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the information server communicates with the IFP BRIDGE database 1119, operating systems, other program components, user interfaces, Web browsers, and/or the like.
[00109] Access to the IFP BRIDGE database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the IFP BRIDGE. In one embodiment, the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields. In one embodiment, the parser may generate queries in standard SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the IFP BRIDGE as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser.
[o o iio] Also, an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
User Interface [o o iii] The function of computer interfaces in some respects is similar to automobile operation interfaces. Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, functionality, and status. Computer interaction interface elements such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) similarly facilitate the access, operation, and display of data and computer hardware and operating system resources, functionality, and status. Operation interfaces are commonly called user interfaces. Graphical user interfaces (GUIs) such as the Apple Macintosh Operating System's Aqua, IBM's OS/2, Microsoft's Windows 2OOO/2OO3/3-i/95/98/CE/Millenium/NT/XP/Vista/7 (e.g.,Aero), Unix's X-Windows (e.g., which may include additional Unix graphic interface libraries and layers such as K Desktop Environment (KDE), mythTV and GNU Network Object Model Environment (GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc. interface libraries such as, but not limited to, Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! User Interface, any of which may be used and) provide a baseline and means of accessing and displaying information graphically to users. [o o ii2] A user interface component 1117 is a stored program component that is executed by a CPU. The user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as already discussed. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system. A user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like. The user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Web Browser [o o ii3] A Web browser component 1118 is a stored program component that is executed by a CPU. The Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. Secure Web browsing may be supplied with I28bit (or greater) encryption by way of HTTPS, SSL, and/or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/ or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Of course, in place of a Web browser and information server, a combined application may be developed to perform similar functions of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the IFP BRIDGE enabled nodes. The combined application may be nugatory on systems employing standard Web browsers.
Mail Server [00114] A mail server component 1121 is a stored program component that is executed by a CPU 1103. The mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and/or the like. The mail server may allow for the execution of program components through facilities such asASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like. The mail server can route, foreal-worldard, and process incoming and outgoing mail messages that have been sent, relayed and/or othereal- worldise traversing through and/or to the IFP BRIDGE. [00115] Access to the IFP BRIDGE mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system. [00116] Also, a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
Mail Client [00117] A mail client component 1122 is a stored program component that is executed by a CPU 1103. The mail client may be a conventional mail viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like. Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/ or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages.
Cryptographic Server [00118] A cryptographic server component 1120 is a stored program component that is executed by a CPU 1103, cryptographic processor 1126, cryptographic processor interface 1127, cryptographic processor device 1128, and/or the like. Cryptographic processor interfaces will allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a conventional CPU. The cryptographic component allows for the encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/ or the like. The cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like. Employing such encryption security protocols, the IFP BRIDGE may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network. The cryptographic component facilitates the process of "security authorization" whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for an digital audio file. A cryptographic component may communicate to and/or with other components in a component collection, including itself, and/ or facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable the IFP BRIDGE component to engage in secure transactions if so desired. The cryptographic component facilitates the secure accessing of resources on the IFP BRIDGE and facilitates the access of secured resources on remote systems; e.g.,it may act as a client and/or server of secured resources. Most frequently, the cryptographic component communicates with information servers, operating systems, other program components, and/or the like. The cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. The IFP BRIDGE Database [00119] The IFP BRIDGE database component 1119 may be embodied in a database and its stored data. The database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored data. The database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; e.g., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the "one" side of a one-to-many relationship. [00120] Alternatively, the IFP BRIDGE database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like. Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of functionality encapsulated within a given object. If the IFP BRIDGE database is implemented as a data-structure, the use of the IFP BRIDGE database 1119 may be integrated into another component such as the IFP BRIDGE component 1135. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated. [o o i2i] In one embodiment, the database component 1119 includes several tables uigsL-e. An applications table 1119a includes fields such as, but not limited to: application_ID, application_name, settings, configurations, saved_states, sensor_inputs, application_data, and/or the like. A Protocols table 1119b may include fields such as, but not limited to: protocol_ID, protocol_name, protocol_type, format, access_data, server_data, device_configuration, avatar_configuration, and/or the like. A device table 1119c may include fields such as, but not limited to: device_ID, device_parameters, device_type, device_data, configuration, and/or the like. An account table ni9d may include fields such as, but not limited to: account_ID, account_profile, account_parameters, account_avatar, account_data, configuration, and/or the like. A virtual-world table ni9e may include fields such as, but not limited to: virtual-world_ID, virtual-world_parameters, virtual-world_name, virtual- world_data, virtual-world_configuration, and/or the like. A sensor table ni9f may include fields such as, but not limited to: sensor_ID, sensor_parameters, sensor_type, sensor_data, sensor_configuration, sensor_history, and/or the like. A user table ni9g may support and/or track multiple entity accounts on a IFP BRIDGE, and includes fields such as, but not limited to: user_ID, user_name, user_account_type, user_pasword, toy_ID, toy_hardware, application_authorization_info, account_info, and/or the like. An actions table 1019I1 may define IFP BRIDGE actions and the associated responses, including fields such as, but not limited to: action_ID, action_name, sensor_ID, action_parameters, toy_ID, action_response, action_msg, action_response_sensor, and/or the like. [o o i22] In one embodiment, the IFP BRIDGE database may interact with other database systems. For example, employing a distributed database system, queries and data access by search IFP BRIDGE component may treat the combination of the IFP BRIDGE database, an integrated data security layer database as a single database entity. [00123] In one embodiment, user programs may contain various user interface primitives, which may serve to update the IFP BRIDGE. Also, various accounts may require custom database tables depending upon the environments and the types of clients the IFP BRIDGE may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (e.g., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components ni9a-h. The IFP BRIDGE may be configured to keep track of various settings, inputs, and parameters via database controllers. [00124] The IFP BRIDGE database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the IFP BRIDGE database communicates with the IFP BRIDGE component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data.
The IFP BRIDGES [00125] The IFP BRIDGE component 1135 is a stored program component that is executed by a CPU. In one embodiment, the IFP BRIDGE component incorporates any and/or all combinations of the aspects of the IFP BRIDGE that was discussed in the previous figures. As such, the IFP BRIDGE affects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks.
[00126] The IFP BRIDGE component enables the real-world-virtual-world interactions and data synchronization and/or the like and use of the IFP BRIDGE.
[00127] The IFP BRIDGE component enabling access of information between nodes may be developed by employing standard development tools and languages such as, but not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI) (Objective-) C (++), C# and/or .NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, procedural and object oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, web application server extensions, web development environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo! User Interface; and/or the like), WebObjects, and/or the like. In one embodiment, the IFP BRIDGE server employs a cryptographic server to encrypt and decrypt communications. The IFP BRIDGE component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the IFP BRIDGE component communicates with the IFP BRIDGE database, operating systems, other program components, and/or the like. The IFP BRIDGE may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
Distributed IFP BRIDGES [00128] The structure and/or operation of any of the IFP BRIDGE node controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/ or deployment. Similarly, the component collection may be combined in any number of ways to facilitate deployment and/or development. To accomplish this, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion.
[00129] The component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques. [00130] The configuration of the IFP BRIDGE controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/ or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like.
[00131] If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), local and remote application program interfaces Jini, Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter- application communication or within memory spaces of a singular component for intra- application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing functionality, which in turn may form the basis of communication messages within and between components. For example, a grammar may be arranged to recognize the tokens of an HTTP post command, e.g.: w3c -post http : // . . . Vσluel
[00132] where Valuei is discerned as being a parameter because "http://" is part of the grammar syntax, and what follows is considered part of the post value. Similarly, with such a grammar, a variable "Valuei" may be inserted into an "http://" post command and then sent. The grammar syntax itself may be presented as structured data that is interpreted and/or other wise used to generate the parsing mechanism (e.g., a syntax description text file as processed by lex, yacc, etc.). Also, once the parsing mechanism is generated and/or instantiated, it itself may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or readily available parsers (e.g., the SOAP parser) that may be employed to parse communications data. Further, the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment. [00133] The entirety of this application (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, and othereal-worldise) shows by way of illustration various embodiments in which the claimed inventions may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed inventions. [00134] It is to be further understood that, depending on the particular needs and/ or characteristics of IFP BRIDGE user(s), associated devices, applications, control configurations, interface devices, associated data, communication and/or network frameworks, hardware configurations, monetization models, and/or the like, various embodiments of the IFP BRIDGE may be implemented that enable a great deal of flexibility and customization. The instant disclosure discusses embodiments and/ or applications of the IFP BRIDGE directed to interactions between toys, social networks, and/or computer generated environments. However, it is to be understood that the system described herein may be readily configured and/or customized for a wide range of other applications and/or implementations. For example, aspects of the IFP BRIDGE may be adapted for non-toy related interaction applications; include additional and/or alternative types of monitoring (e.g., security) and/or sensors (e.g., face recognition, location, temperature, pressure, position, elevation, sound/light intensity, and/or the like); and/or the like applications and/or components. It is to be understood that the IFP BRIDGE may be further adapted to other implementations or communication, interface, and/or control applications. [00135] As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the invention, and inapplicable to others. In addition, the disclosure includes other inventions not presently claimed. Applicant reserves all rights in those presently unclaimed inventions including the right to claim such inventions, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims.

Claims

What is claimed is: l. A processor-implemented interworldinteraction method, comprising: registering a real-world toy-device with a computer generated environment; receiving data relating to an event; determining a responsive action corresponding to the received event data; issuing instructions to effectuate the determined responsive action; monitoring for completion of the issued instructions; and sending status update data to the computer generated environment.
2. The method of claim l, wherein the computer generated environment include a user computing device.
3. The method of claim 1, wherein the computer generated environment include any of a social media server, a crowd sourcing server and a blog/microblog server.
4. The method of claim 1, wherein the registration of the real-world toy- device with the computer generated environment comprises: querying a computer generated environment within a local area network; establishing a communications path with the queried computer generated environment; submitting registration information to the computer generated environment; synchronizing data with the computer generated environment; and receiving a registration notification with the computer generated environment.
5. The method of claim 4, wherein the local area network may be any of Bluetooth and Wi-Fi.
6. The method of claim 4, wherein the registration information includes hardware identification data of the real-world toy-device.
7. The method of claim 4, wherein the synchronized data comprises an action definition list.
8. The method of claim 1, wherein the registration of the real-world toy- device with the computer generated environment comprises: receiving a notification of registration when the real-world toy-device is powered on; and synchronizing data with the computer generated environment.
9. The method of claim 1, wherein receiving data relating to an event comprises: determining a type of the received event data, wherein the event data may comprise any of toy-device sensor data, environment stimuli data, and a synchronization request from a computer generated environment.
10. The method of claim 9, wherein the toy-device sensor data may indicate any of face recognition, location, temperature, pressure, position, elevation, and sound/light intensity.
11. The method of claimcj, wherein the environment stimuli data is received from another real-world toy-device.
12. The method of claim 9, further comprising: if the received event data comprises a synchronization request, establishing a communications channel with the computer generated environment, and receiving synchronization data from the computer generated environment.
13. The method of claim 12, further comprising: if the received synchronization data comprises new action definitions, update an action definition list; if the received synchronization data comprises new action data, determining a responsive action corresponding to the received event data; and if the received synchronization data comprises status update indications, issuing instructions to reflect the status update.
14. The method of claim 1, wherein determining a responsive action corresponding to the received event data comprises: querying an action definition list to interpret the event data; and retrieving instructions responsive to the event data based on the query.
15. A processor-implemented interworldinteraction method, comprising: registering a real-world toy-device with a computer generated environment; receiving data from a toy-device in the real world; determining on a processor a computer generated environment toy- account associated with the toy-device; updating the determined toy- account based on the received real-world data; receiving data from the computer generated environment profile relating to the toy-account; updating the toy- account based on the received computer generated environment profile data; analyzing the toy-account to determine whether update information is to be sent to the toy-device in the real world; sending information to the toy-device if indicated by the analysis; analyzing the toy-account to determine whether update information is to be sent to the profile associated with the toy-device; and issuing instructions to update the profile associated with the toy-device if indicated by the analysis.
16. An interworldinteraction system, comprising: means for registering a real-world toy-device with a computer generated environment; means for receiving data relating to an event; means for determining a responsive action corresponding to the received event data; means for issuing instructions to effectuate the determined responsive action; means for monitoring for completion of the issued instructions; and means for sending status update data to the computer generated environment.
Y]. An interworldinteraction system, comprising: means for registering a real -world toy-device with a computer generated environment; means for receiving data from a toy-device in the real world; means for determining on a processor a computer generated environment toy-account associated with the toy-device; means for updating the determined toy-account based on the received real-world data; means for receiving data from the computer generated environment profile relating to the toy-account; means for updating the toy-account based on the received computer generated environment profile data; means for analyzing the toy-account to determine whether update information is to be sent to the toy-device in the real world; means for sending information to the toy-device if indicated by the analysis; means for analyzing the toy-account to determine whether update information is to be sent to the profile associated with the toy-device; and means for issuing instructions to update the profile associated with the toy-device if indicated by the analysis.
i8. An interactive communication feedback toy-device, comprising: a memory; a processor disposed in communication with said memory, and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to: receive information from a toy-account associated with a computer generated environment, the toy-account corresponding to the toy-device; determine the presence of at least one other toy-device based on monitoring and analysis; receive information from an other toy-device determined to be present; verify validity of received information from an other toy-device determined to be present based on the received information from the toy-account; communicate with the other toy-device based on verified validity of information received from said other toy-device; issue instructions to perform actions based on communications with the other toy-device; and transmit information to update the toy-account based on the communications with the other toy-device and issued instructions.
19. An interactive toy-device communication feedback apparatus, comprising: a memory; a processor disposed in communication with said memory, and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to: monitor for data relating to computer generated environment interactions, wherein computer generated environment interactions include social networking interactions; update a toy-device record based on the monitored data; determine an action corresponding to the updated toy-device record; issue instructions to effectuate the determined action; monitor for completion of the issued instructions; and update the toy-device record based on the monitored completion of the issued instructions.
20. A processor-readable medium storing a plurality of processing instructions, comprising issuable instructions by a processor to: register a real-world toy-device with a computer generated environment; receive data from a toy-device in the real world; determine a computer generated environment toy-account associated with the toy-device; update the determined toy-account based on the received real-world data; receive data from the computer generated environment profile relating to the toy- account; update the toy-account based on the received computer generated environment profile data; analyze the toy- account to determine whether update information is to be sent to the toy-device in the real world; send information to the toy-device if indicated by the analysis; analyze the toy-account to determine whether update information is to be sent to the profile associated with the toy-device; and issue instructions to update the profile associated with the toy-device if indicated by the analysis.
21. A processor-readable medium storing a plurality of processing instructions, comprising issuable instructions by a processor to: register a real-world toy-device with a computer generated environment; receive data relating to an event; determine a responsive action corresponding to the received event data; issue instructions to effectuate the determined responsive action; monitor for completion of the issued instructions; and send status update data to the computer generated environment.
PCT/US2010/024196 2009-02-13 2010-02-13 Apparatuses, methods and systems for an interworld feedback platform bridge WO2010093995A1 (en)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US15259509P 2009-02-13 2009-02-13
US61/152,595 2009-02-13
US21952609P 2009-06-23 2009-06-23
US61/219,526 2009-06-23
PCT/US2010/023961 WO2010093831A1 (en) 2009-02-11 2010-02-11 Apparatuses, methods and systems for an interactive proximity display tether with remote co-play
USPCT/US2010/023961 2010-02-11

Publications (1)

Publication Number Publication Date
WO2010093995A1 true WO2010093995A1 (en) 2010-08-19

Family

ID=42562086

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2010/024196 WO2010093995A1 (en) 2009-02-13 2010-02-13 Apparatuses, methods and systems for an interworld feedback platform bridge

Country Status (1)

Country Link
WO (1) WO2010093995A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8321364B1 (en) 2012-02-08 2012-11-27 Google Inc. Method and system for including robots into social networks
WO2014001213A1 (en) * 2012-06-26 2014-01-03 BSH Bosch und Siemens Hausgeräte GmbH Communication to and from a household appliance
CN109361563A (en) * 2018-10-31 2019-02-19 广东电网有限责任公司 A kind of substation DNP specification adjustment method
FR3076152A1 (en) * 2017-12-21 2019-06-28 Orange VALIDATION OF PERSONAL DATA OF A USER
US11376743B2 (en) * 2019-04-04 2022-07-05 Joyhaptics Oy Systems and methods for providing remote touch

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020068500A1 (en) * 1999-12-29 2002-06-06 Oz Gabai Adaptive toy system and functionality
US20020090985A1 (en) * 2000-09-07 2002-07-11 Ilan Tochner Coexistent interaction between a virtual character and the real world
US20050154594A1 (en) * 2004-01-09 2005-07-14 Beck Stephen C. Method and apparatus of simulating and stimulating human speech and teaching humans how to talk
US20060224546A1 (en) * 2003-03-25 2006-10-05 Daniel Ballin Aparatus and method for generating behaviour in an object
US20070197297A1 (en) * 2006-02-21 2007-08-23 Witchey Nicholas J Apparatus and Methods of Physical Game Components
US20070211047A1 (en) * 2006-03-09 2007-09-13 Doan Christopher H Persistent authenticating system and method to map real world object presence into virtual world object awareness
US20080040297A1 (en) * 2003-12-31 2008-02-14 Ganz System and method for toy adoption marketing
US20080280684A1 (en) * 2006-07-25 2008-11-13 Mga Entertainment, Inc. Virtual world electronic game

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020068500A1 (en) * 1999-12-29 2002-06-06 Oz Gabai Adaptive toy system and functionality
US20020090985A1 (en) * 2000-09-07 2002-07-11 Ilan Tochner Coexistent interaction between a virtual character and the real world
US20060224546A1 (en) * 2003-03-25 2006-10-05 Daniel Ballin Aparatus and method for generating behaviour in an object
US20080040297A1 (en) * 2003-12-31 2008-02-14 Ganz System and method for toy adoption marketing
US20050154594A1 (en) * 2004-01-09 2005-07-14 Beck Stephen C. Method and apparatus of simulating and stimulating human speech and teaching humans how to talk
US20070197297A1 (en) * 2006-02-21 2007-08-23 Witchey Nicholas J Apparatus and Methods of Physical Game Components
US20070211047A1 (en) * 2006-03-09 2007-09-13 Doan Christopher H Persistent authenticating system and method to map real world object presence into virtual world object awareness
US20080280684A1 (en) * 2006-07-25 2008-11-13 Mga Entertainment, Inc. Virtual world electronic game

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8321364B1 (en) 2012-02-08 2012-11-27 Google Inc. Method and system for including robots into social networks
WO2014001213A1 (en) * 2012-06-26 2014-01-03 BSH Bosch und Siemens Hausgeräte GmbH Communication to and from a household appliance
FR3076152A1 (en) * 2017-12-21 2019-06-28 Orange VALIDATION OF PERSONAL DATA OF A USER
CN109361563A (en) * 2018-10-31 2019-02-19 广东电网有限责任公司 A kind of substation DNP specification adjustment method
US11376743B2 (en) * 2019-04-04 2022-07-05 Joyhaptics Oy Systems and methods for providing remote touch

Similar Documents

Publication Publication Date Title
US11924364B2 (en) Interactive networked apparatus
US20120079080A1 (en) Apparatuses, Methods and Systems For An Interactive Proximity Display Tether With Remote Co-Play
US10888790B2 (en) Low-friction response in a social game
US20120077586A1 (en) Apparatuses, methods and systems for an interactive proximity display tether
JP7470137B2 (en) Video tagging by correlating visual features with sound tags
EP3095091B1 (en) Method and apparatus of processing expression information in instant communication
US9757654B2 (en) Methods and systems for assembly of crews for facilitating execution of social game activity
US20140351720A1 (en) Method, user terminal and server for information exchange in communications
WO2014023838A2 (en) Platform independent multimedia playback apparatuses, methods and systems
US8982133B2 (en) Portable virtual characters
US20150106226A1 (en) Gaming marketplace apparatuses, methods and systems
US20150298315A1 (en) Methods and systems to facilitate child development through therapeutic robotics
WO2010093995A1 (en) Apparatuses, methods and systems for an interworld feedback platform bridge
EP2471005A1 (en) Apparatuses, methods and systems for a distributed object renderer
US11541317B2 (en) Automated weapon selection for new players using AI
US20240123350A1 (en) Online Gaming Platform Systems, Methods, and Apparatus
Ng et al. Toys and mobile applications: current trends and related privacy issues
US20150140896A1 (en) System, method, device and applications to connect devices and people over a hybrid social network
Chang et al. A review on ethical issues for smart connected toys in the context of big data
Murala et al. The Internet of Things in Developing Metaverse
KR102654344B1 (en) Method and system for evaluating chat-bot based on blockchain
US20240066399A1 (en) Smooth switchover of computer game control
Klisman et al. LogMe: An Application for Generating Logs in Immersive Interactions for UX Evaluation.
WO2021231404A1 (en) Simulating motion of computer simulation characters to account for simulated injuries to the characters using current motion model
JP2021060685A (en) Information processing system and information processing program

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10741850

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 24/11/2011)

122 Ep: pct application non-entry in european phase

Ref document number: 10741850

Country of ref document: EP

Kind code of ref document: A1