Techniques to facilitate communications between adult toys over a network

Abstract

This disclosure relates to haptic stimulation and provides improved techniques for permitting an adult toy of one manufacturer to drive reactions of a second adult toy (or an accessory) of a potentially different manufacturer. In one embodiment, sensor data from a first toy is buffered and resampled at a constant data rate to generate a genericized data stream. This data is then processed (e.g., filtered, combined or otherwise modified) to generate interpretations pertaining to toy manipulation, for example, inferences as to toy motion. Upon detecting defined conditions, a translation or mapping function then converts identified actions / manipulations to commands for actions or reactions of the second toy or accessory. Techniques can further be applied for mitigating skew between the timing of these actions / reactions and linked audiovisual material, thereby providing for improved content and / or an improved experience.

Description

TECHNIQUES TO FACILITATE COMMUNICATIONS BETWEEN ADULT TOYS OVER A NETWORKCROSS-REFERENCE TO RELATED APPLICATIONS.

[0001] This disclosure claims the benefit of US Provisional Patent Application No. 63 / 662731, filed on June 21, 2024, on behalf of first-named inventor Karoly Papp, for "Methods And Systems To Facilitate Interaction Between Adult Toys Over A Network." Each aforementioned patent application is hereby incorporated by reference.BACKGROUND.

[0002] Technologies have recently been developed which permit interaction between adult toys over a network. For example, some adult toys provide Bluetooth or other wired or wireless functionality which permits those toys to interact with a computer or other smart device, e.g., a cell phone of a human user, who is the adult toy owner. Some manufacturers have further developed compatible toys, i.e., such that multiple adult toys from the same manufacturer can interact with each other through a network. For those toys that can interact, a complex pairing process is typically required, including the use of special software specific to the manufacturer, and involving the sending, receiving and accepting of an invitation in order to connect compatible devices, i.e., generally only specific, specially-designed compatible devices from a single manufacturer. These technologies represent a potentially significant market, but thus far, these limitations have inhibited extensive usage.

[0003] More specifically, a manufacturer which does offer connectable-toys typically utilizes a proprietary device control format or network signaling format, which makes it difficult to link those devices with any other toys or devices (e.g., accessories), whether or not from the same manufacturer. These formats can feature unknown commands, unknown and / or variable data update or expression rates, and different manners of expressing data, making it quite difficult to link one device to another other than through the use of a single manufacturer's software or system; as a practical matter, there generally are no easy methods for readily connecting devices, even if those devices are individually capable of receiving remotely-issued commands or otherwise making available data which represents their use or manipulation.

[0004] A definite need exists for solutions to these problems. Ideally, such solutions would provide one or more systems or components which can facilitate interface / exchange between a first adult toy, i.e., whether or not powered, but having sensor functionality, and a wide range of second devices, whichcan each be second adult toys and / or an accessories having one or more motors, vibrators or other actuators. Ideally still, such solutions would provide the facility the ability interconnect devices from different manufacturers and also further the potential market for these devices.

[0005] The present disclosure addresses these needs and provides further, related advantages.BRIEF DESCRIPTION OF THE DRAWINGS.

[0006] FIG. 1 is a block diagram showing actions associated with a first adult toy.

[0007] FIG. 2 is a block diagram showing actions associated with a second device, e.g., an adult toy 203 and / or an accessory 209.

[0008] FIG. 3 illustrates a hypothetical network 301, having a first end (e.g., toy 309 and associated computer or other "smart device" 313), a second end (e.g., toy 311 and associated computer or other smart device 303) and one or more servers; in this example, the one or more servers also route an audio and / or visual ("audiovisual") signal.

[0009] FIG. 4 is a block diagram associated with initiation of a peer-to-peer or broadcast session, in one embodiment.

[0010] FIG. 5 shows functions associated with an embodiment which processes data from one or more sensors.

[0011] FIG. 6 shows an embodiment which processes sensor outputs to generate standardized and / or parametrized sensor data and / or motion signals; these signals can then optionally be interpreted and used to control a downstream device (e.g., a second device such as an adult toy and / or in an accessory).

[0012] FIG. 7 is a block diagram of an embodiment which interprets sensor data and translates that data to commands for controlling an actuator (e.g., in a second adult toy and / or an accessory).

[0013] FIG. 8 is a block diagram of an embodiment which controls actuation of an adult toy and / or an accessory.

[0014] FIG. 9 is a block diagram of an embodiment which discovers an adult toy and / or accessory, and associated capabilities.

[0015] FIG. 10A shows an example of resampled data arriving from a sensor in an adult toy.

[0016] FIG. 10B shows the resampled data from FIG. 10A after it has been processed to reduce noise.

[0017] FIG. IOC shows the noise processed data from FIG. 10B, with a zero level (DC level) superimposed.

[0018] FIG. 10D shows the noise processed data from FIG. IOC with vertical lines superimposed, to denote crossings of the data with the DC level ("zero crossings") with respect to time.

[0019] FIG. 11 shows some possible pairings / mappings that can be created between a transmitting device 1103 and a receiving device 1105.

[0020] The subject matter defined by the enumerated claims may be better understood by referring to the following detailed description, which should be read in conjunction with the accompanying drawings. This description of one or more particular embodiments, set out below to enable one to build and use various implementations of the technology set forth by the claims, is not intended to limit the enumerated claims, but to exemplify their application. Without limiting the foregoing, this disclosure provides several different examples of (1) a system, for example, employed at a transmitting end, to interpret actions / manipulations of a first, potentially unknown adult toy, (2) a networked or other system, which for example, interprets sensed data and / or actions of a first adult toy and generates consequent actions / reactions, which can then be commanded on a second device (e.g., a second adult toy or accessory), (3) a receiving device, which controls execution of commands for control of an actuator, for example, in an adult toy or accessory. In some embodiments, synchronization techniques can optionally also be used at any locations in a communication system (including in these embodiments) to help synchronize data and / or commands with associated audio or video (e.g., with an audiovisual signal). These various techniques can be embodied as software / firmware for use with a given component or system, in the form of an adult toy or an accessory, in the form of a service (e.g., a local service or a cloud service, such as a live streaming service), in the form of a recorded media having sensor data / toy commands combined with audiovisual material, or in some other manner. While specific examples are presented, the principles described herein may also be applied to other systems, applications, methods and devices as well.DETAILED DESCRIPTIONI. INTRODUCTION.

[0021] This disclosure presents a number of different inventions which can be used together, in the alternative, or in any desired combination. The embodiments below are example implementations only. It is specifically contemplated that the individual components of the various embodiments described below can be mixed and matched in any desired permutation and / or combination, regardless of whether they are presented together in a single, dedicated FIG or integrated, focused discussion.

[0022] In many of the embodiments described below, it is assumed that there is a first adult toy having one or more sensors; this first adult toy can optionally be a powered device having an actuator, but it need not be, e.g., it can also be a device simply having one or more sensors. It is also assumed for some embodiments that there is a second, powered device having one or more actuators, e.g., this can optionally be an adult toy, such as a vibrator, or an accessory (e.g., such as a device which is actuated to generate light, sound, color, or other actions, whether or not specifically usable as an adult toy). Many of the embodiments discussed below use techniques for interacting with sensors and / or sensed data which are manufacturer-agnostic, and which therefore provide ready adaptation and ready means for adapting to and interacting with many different devices, whether or not these devices are specifically configured to be compatible with other devices. Similarly, many of the embodiments discussed below use techniques for interacting with toys having actuators in a manner which is agnostic to manufacturer-specific command or signaling formats. In some embodiments discussed below, toy sensor data or actions can be linked with an audio or video ("audiovisual") recording or feed; for example, a first user can connect to a digital service (e.g., via computer, smart phone, web browser, etc.) to provide or receive content in tandem with the actions of a toy, either sensed or commanded. Because audio and / or video transport, buffering, and / or rendering typically uses defined-processes, e.g., which can create relative delays or "skew" between the timing of data / commands and the audiovisual signal, some techniques employ special measures for synchronizing audiovisual material with sensor data or commanded toy actions, or vice-versa.

[0023] One embodiment provides a system that receives sensor data from a first adult toy and generates data and / or descriptions of toy manipulation or usage that can be used to generate commands to control a second device, for example a second adult toy or an accessory. The first adult toy need not have any powered actuators, though this is not precluded, and the sensor data can include positioninformation, rotation information, pressure information, motion information, or other types of information, such as frequency, displacement, phase, color, brightness, sound, speed, acceleration, voltage, current, direction, or information regarding other parameters, or a combination of these things, as appropriate. To facilitate interface with toys from different manufacturers, the sensor data is not directly used in some embodiments, but rather is buffered and is resampled at a standardized (e.g., manufacturer-agnostic, constant data) rate, for example, 5-, 10-, 20- or more samples per second in some embodiments. Thus genericized, the resulting "raw" data stream can then optionally be scaled and / or otherwise processed as desired; in one nonlimiting example, a stream of re-sampled sensor data having a constant data rate can be processed for smoothing (e.g., to minimize noise) and to identify / predict position and / or motion or other parameters. Data from the first adult toy, representing its actuation, can thus be stored and / or sent to a network destination, for downstream processing and / or translation to obtain a command action or reaction of a second device (e.g., by controlling an actuator of that device).

[0024] A few examples here would be helpful. A phallic device at a first location can be monitored, using one to potentially many sensors; resampled data, using techniques taught herein, can produce a stream of data having a standardized format, e.g., constant rate of update of raw data, one for each degree of freedom, if desired. This data can be processed in any desired manner, for example, to identify relative or absolute, position, orientation, pressure or other parameters, and / or other features of this device (e.g., motion or a pattern). Any of this data can optionally be used to directly drive (e.g., mirrored actions) of a second device and / or tested against predetermined conditions, with a match being used to trigger linked actions of the second device, for example, a trigger actions of male masterbator, a vibrator, an accessory device, etc. Note that the actions of the second device need not necessarily match those of the first device, i.e., the resampling and motion identification / translation functions permit translation to any linked, potentially different action of a recipient device, and the interpretation function used to identify a predetermined condition associated with the first ("driving") device can be as complex as desired. For example, one contemplated embodiment uses sensed position data of the first adult toy to drive reactions of a second device when the movement rate and / or frequency of motion of the first toy is low, but then, as motion of the first adult toy increases, in a manner meeting one or more thresholds / conditions, the processing algorithm instead simply reports frequency and / or predictive motion parameters. As with any 'interpretation' function described herein, actions of a first adult toy, based on one or more resampled or genericized data streams are interpreted by detecting satisfaction of one or more programmed conditions, for example, a velocity greater than a threshold value; any combination of one or more thresholds, parameters and / or Boolean logic can be used for this purpose.Note also that a second adult toy is not required for many embodiments, e.g., motion, light patterns, sound, or other sensed data associated with a first device can simply be generated and stored. Alternatively, sensed data can be used to drive a second device which is not a toy, but rather is an accessory device (for example, ambient lighting, sound, color, or scripted patterns of these things), in lieu of or in addition to a second adult toy. These descriptions represent introductory, non-limiting examples only; this is to say, some embodiments feature software only (e.g., a downloadable application or "app") used at a transmitting end device to interpret manipulations of an adult toy, while other embodiments can be implemented solely in a network or in a downstream network or device.

[0025] Techniques provided by this disclosure can be advantageously applied to live audio and / or video ("audiovisual") adult streaming services. In this regard, as noted, delays (including without limitation Internet transmission delays) can be especially significant for live streaming of shows. Other types of delays can occur with audiovisual rendering, for example, following receipt of an audiovisual signal, thus giving rise to associated synch issues. In some embodiments, therefore, sensor data and / or commands generated from sensor data and / or audiovisual data are processed so as to facilitate synching. One version of these techniques inserts indices in the sensor or command data, e.g., a time stamp, to identify when sampled data and / or commands should be executed relative to an associated audiovisual stream, or vice-versa. In variations, audiovisual stream, sensor data or device command lag time can be computed and applied at one or more of (1) a first, transmitting end, (2) a network midpoint, or (3) a second, receiving end, for example, to buffer or delay execution of commands or video so as to negate lag. In still other embodiments, an execution time can optionally be precomputed, e.g., based on lag time computation or other delays, and can be applied to schedule and / or transmit commands (from a transmitting end, a network node, or at a receiving end), to achieve synch. In yet another application, an adult show featuring a performer can be prerecorded, and a data stream associated with manipulations of a first adult toy used during the show can be processed, using the techniques mentioned earlier, with data and / or resultant commands intended for a second device then being added to the recorded stream, for later distribution and / or playback; such a prerecorded expression can also optionally include synching data, in a manner that allows for alignment of commanded actions of a second, driven device (e.g., toy or accessory), so as to preserve relative timing between manipulations of the first adult toy with any performer expressions captured by originally recorded audio or video. Many variations of these principles will naturally occur to those having ordinary skill in the art.

[0026] These and other features will be further elaborated upon below.

[0027] Prior to proceeding, however, it would be helpful to first discuss several specific terms. A "toy" as used herein refers to an adult toy, including without limitation, a vibration device or vibrator (bullet, rabbit, wand, phallic, wearable or otherwise), a dildo, male masterbator, a thrusting device or indeed, any other powered or unpowered device used for human sensual stimulation; in some cases, such a device does not move or vibrate, but rather, produces other sensory stimuli such as heat, cold, light, sound, pressure, a vacuum, etc. An "accessory" as used herein refers to a device, not necessarily directly used for sexual stimulation, but rather, to enhance a mood, show, performance and so forth, for example, a background light, an auditory device, or physical device; in some embodiments discussed herein, an accessory can be driven or controlled in response to actions of a remote toy, for example, with a light which changes or emits patterns which are responsive to how a toy is manipulated - this example is illustrative only. When used in the context of an adult toy or device for human sensory stimulation, it typically refers to either an adult "toy" or an accessory." It should be understood that contemplated embodiments can include "hardware logic," "circuits" or "circuitry" (each meaning one or more electronic circuits). Generally speaking, and unless otherwise specified, these terms can include analog and / or digital circuitry, and can be, in nature, special purpose or general purpose. For example, as used herein, the term "circuitry" for performing a particular function can include one or more electronic circuits that are either "hard-wired" or are configurable circuits to perform the stated function (i.e., in some cases without assistance of instructional logic), and the term can include a microcontroller, microprocessor, FPGA or other form of processor which is general in design but which runs software or firmware (e.g., instructional logic) that causes or configures general circuitry (e.g., configures or directs a circuit processor) to perform the particular function. Note that as these statements imply, "circuits" and "circuitry" for one purpose are not necessarily mutually-exclusive to "circuits" or "circuitry" for another purpose, e.g., such terms indicate that one or more circuits are configured to perform a function, and one, two, or even all circuits can be shared with "circuitry" to perform another function (indeed, such is often the case where the "circuitry" includes a processor); this is to say, "circuitry to perform (function X)" and "circuitry to perform (function Y)" can encompass exactly the same circuitry or respective circuits, depending on implementation. Related to these points, the term "logic" can encompass hardware logic, instructional logic, or both, unless otherwise specified. Instructional logic can be code written or designed in a manner that has certain structure (architectural features) such that, when the code is ultimately executed, the code causes the one or more general purpose machines (e.g., a processor, computer or other machine) each to behave as a special purpose machine, having structure that performs, upon occurrence of defined events, described tasks with respect to processing operands, or else take specificactions or produce specific outputs. Generally speaking, circuits and / or processes described herein can, in some embodiments, be implemented as instructional logic (e.g., as instructions stored on non- transitory machine-readable media or other software logic), as hardware logic, or as any combination or permutation of these things, depending on embodiment or specific design. "Non-transitory," to the extent used herein, refers to any tangible (i.e., physical structure) medium or mediums, irrespective of the type of technology used to express data on that medium and irrespective of the format of data storage; for example, in one case, a particular expression can be optically stored on physical media, and in another case, the particular expression can be magnetically stored on physical media. Thus, when applied to storage and / or computer-readable and / or machine-readable subject matter, the term "non- transitory" indicates that data and / or instructions can be stored on such a physical structure storage medium using optical, magnetic, electronic, resistive and / or other storage formats / technologies, i.e., where some type of physical device, including without limitation, random access memory, hard disk memory, optical memory, a floppy disk, a compact disk ("CD"), a solid state drive ("SSD"), server storage, volatile memory, and / or nonvolatile memory, i.e., a physical thing, is used as the storage medium. Each such medium and / or device can be in standalone form (e.g., a program disk or solid state device, or mass storage servicing an "app store") or embodied as part of a larger mechanism, for example, resident memory that is part of an electronic device such as a smart phone, computer, digital television, automobile, portable device, chip-card, dongle, server, printer, etc., or embodied as one or more such devices. "Instructions" can be implemented in different formats, depending on embodiment; for example, instructions can take form as metadata that when called is effective to invoke a certain action, as Java code or web scripting, as code written in a specific programming language (e.g., as C++ code), as a processor-specific instruction set, or in some other form. Depending on design, the instructions can also be executed by the same processor, different processors or processor cores, FPGAs or other configurable circuits, for example, being adapted for execution by a single computer in some cases, and in other cases, being adapted for execution on a distributed basis, e.g., using one or more servers, web clients, or application-specific devices, not necessarily all operating at the same time. "Module" as used herein refers to a structure (e.g., hardware, or software, or both) dedicated to a specific function; for example, a "first module" to perform a first specific function and a "second module" to perform a second specific function, when used in the context of instructions (e.g., computer code), refers to mutually-exclusive code sets. When used in the context of mechanical or electromechanical structures (e.g., an "encryption module," the term "module" refers to a dedicated set of components which might include hardware and / or software, depending on the purpose of that module). In all cases, the term "module" is used torefer to a specific structure for performing a function or operation that would be understood by one of ordinary skill in the art to which the subject matter pertains as a conventional structure used in the specific art, and not as a "generic placeholder" or "means" for "any structure whatsoever" (e.g., "a team of oxen") for performing a recited function (e.g., "encryption of a digital input"). The term "integrated circuit" (or "IC") typically refers to a structure having at least one die, packaged or otherwise, and, as implied, a single IC and / or die can also be a type of electronic "device." "Audiovisual" should be interpreted as referring to a signal which can have audio, or video or both, i.e., the term "audiovisual" as generally used herein encompasses a purely audio signal. Sometimes in the discussion below, the term "transmitting" or "receiving" will be used in association with a system, device, computer, or communication system node or end; it should be understood that this term refers to whichever system, device, computer, or communication system node or end is currently "transmitting" or "receiving" described data in a network, and that a device can be "transmitting" at one point in time and "receiving" at another. As a non-limiting example of this, an adult toy can have both constituent sensors (e.g., used to sense position or motion) and powered actuators, and either it or its associated system can be referred to as "transmitting" data or commands to a network (e.g., it can be a "transmitting end" of the network for this purpose, relative to another toy for which reactions are commanded responsive to the data or commands which are output) and as "receiving" data or commands from the network (e.g., it can be a "receiving end" of the network for this purpose, driving constituent actuators relative to another remote toy from which it receives sensed data or commands used to trigger those actuators).

[0028] The meaning of other terms used herein should be clear based on context. Note that, to the extent that any other material is incorporated herein by reference, the definitions of this document should be understood to predominate over any inconsistent definitions provided by such incorporated-by- reference materials with respect to the subject matter discussed herein. It is again emphasized that it is expressly contemplated that the various elements discussed above or below, in any embodiment, can be used in any desired permutation or combination regardless of specifically illustrated together in a single common figure or example discussed below. Selection and / or omission of structures for any given design or application is within the level of ordinary skill in the art, and none of the elements / structures discussed below are to be deemed "essential" for any purpose or function.II. EXEMPLARY SYSTEM DESCRIPTIONS AND SESSION INITIATION.

[0029] FIG. 1 illustrates an example of a system 101 associated with a first adult toy 103. The toy isrepresented as an abstract block having one or more sensors 105a-105n; it should be understood that this representation is a proxy for any adult toy, powered or unpowered, including without limitation for example, a vibrator, male masterbator, a plug, a dildo, a pump or ring-based device, or otherwise. The sensors measure one or more manipulations of the adult toy as supported; for example, a given toy can be designed with sensors to measure a position, an orientation, a displacement, a pressure, acceleration, velocity or, indeed, any other quantity capable of being measured. It is noted that for an unpowered device, many different types of sensors may be used, including without limitation, low energy (e.g., passive) RF transponders or other devices. In an exemplary case, and for purposes of illustration only, the toy can be assumed to be a powered vibrator, with the various sensors being powered by the batteries used to also drive vibrator motion. The sensors, as an example, can optionally be designed so as to measure position of and / or orientation of and / or external pressure on (e.g., at different locations on) the vibrator, as controlled by the user, irrespective concurrent use of the vibrator's motor or actuator. In an exemplary case, the vibrator is configured for Bluetooth communication with a digital system (this is conceptually represented by a wireless "lightning" symbol 106). While this digital system is conceptually represented as software function blocks (e.g., 107-127), it should be understood that some or all of these functions can be optionally combined with the toy 103 or with a networked digital device, for example, a cell phone, computer or server, and that the toy can also optionally be made "Internet-ready." For purposes of illustration, it is assumed that the toy is made by a random, unknown manufacturer, and that a command and / or data exchange format, if the toy can be remote controlled by a manufacturer-specific software application ("app"), is unknown, though this need not be the case for all embodiments.

[0030] As indicated by block 107, sensor data from the toy is buffered and is sampled / resampled to obtain digital data representing variation in the sensor data. If the toy is previously unknown to the system, then the system is configured to interact with the particular toy through a definition, configuration or learning process; this configures the system 101 configured to monitor and quantify sensor data, in a manner sufficient to report variation in that data through a range of values, for example, as a data stream representing a constant sample rate. As desired, any format can then be used for reporting or sharing data, for example, the data stream itself, or a derived parameter such as motion, frequency, amplitude etc. (other measures and / or parametrizations may also be used). Optionally, the measured or reported data can also be used to drive / command scripted actions / reactions in a downstream second device, such as another toy or an accessory. As indicated once again by a "lightning icon" 110, in some embodiments, the system 101 can be configured through external programming or user input, for example, in which a specific manufacturer's toy is identified and appropriate sensordefinition information (e.g., number and type of sensors), range of variation of each, and other information is programmed into system 101, to prepare it for use with that specific manufacturer's toy. The system then interacts directly with the toy, for example, overriding or exchanging communications with a manufacturer-specific application that might come with the particular toy.

[0031] A further example might be helpful; although the system 101 is configured to interact with the toy, the format of incoming sensor data might be variable, or occasional or parameterized; to obtain usable data, the incoming sensor data is buffered and is deliberately sampled from this buffer, as updated, at a predetermined rate, e.g., a constant rate such as twenty times a second, to produce a data stream in an ubiquitous format which does not depend on the particular parameter being measured or a manufacturer-specific format. In the case of a toy that interacts via Bluetooth communication, for example, with a local computer, the system 101 can be configured as a software application ("app") on that computer, and it is configured so as to directly interact with the toy using the toy's specific Bluetooth communication (e.g., command) format; the data, however, is advantageously genericized to a stream format, thereby allowing for further, optional processing per techniques discussed herein. The reporting of data to the network, or to another toy, if supported, may then occur using a standardized command format.

[0032] Per numeral 111, the stream of data samples is optionally filtered and / or combined / processed in some manner, for example to remove noise and / or for other processing (113), such as smoothing, antialiasing, parameter derivation, or for other purposes. Note that, as this statement implies, data from more than one sensor can be combined as part of this filtering / processing / combination process, for example, data from multiple position sensors or representing different degrees of freedom can be algorithmically processed to derive quantities such as average position, acceleration, velocity, attitude or rotation, pressure, and / or other parameters. A set of output data, optionally different from the stream of samples, can then be output, generally representing manipulation of the toy, for example, expressed in a generic format per numeral 115, in a parameterized format 117, or in some other manner (e.g., a stream of sensor data, 119). The information being output can take the form of one or multiple channels (121), optionally with a descriptor or applied name for each channel / data type, per numeral 123. For example, in one embodiment discussed below, data from one or more sensors is processed to generate frequency, amplitude and position values representing a single degree of freedom of manipulation of the adult toy; this information can be expressed as a single channel, and through inclusion of additional channels, data representing other degrees of freedom, if supported by device sensors, canalso be reported and / or expressed in the same or a different manner. Although not required for all embodiments, techniques can also be employed for adding audiovisual scheduling and or synchronization information to the quantified toy actuation data, for example, adding a time stamp or other audiovisual indice to reported data, per numeral 125. This data can then be transmitted through a network to a remote destination, e.g., a service and / or destination device, using a standardized network transmission format (e.g., a WAN transmission format, such as Internet packets routed to a specific internet protocol address, or IP address), as once again represented by a "lightning icon" 133. As implied by numeral 127, this format advantageously features a standardized command / data packet schema and is optionally encrypted, e.g., using a asymmetric key pair associated with system 101 or device 103, a symmetric session key, or another encryption / encapsulation mechanism, for security and / or privacy reasons. As indicated by storage media icon 131, this information can also or instead be recorded and stored (e.g., optionally with associated audio or visual material, for later use or streaming). [Note that while the storage media icon is seen as a floppy disk, this representation is a proxy for any type of physical storage medium, e.g., random access memory, read only memory, flash storage, optical storage, a digital video disk, or indeed, any other conventional physical storage medium.] The resultant transported or stored content / media can then be used to drive actions / reactions by one or more other toys or accessories, e.g., either on a "live" basis or at a later time (e.g., synchronized with a delayed or replayed audiovisual signal).

[0033] Another embodiment takes the form of a downstream system 201 where actions / reactions are to be driven on a second device, for example, a second adult toy 203 or optionally an accessory 209. [Note that this accessory 209 is graphically depicted as a "lamp" having a light source, but once again, this depiction should be understood to be a proxy for any type of device that will be driven in response to measured actions / manipulations of an upstream toy; for example, accessory 209 can be used to provide lighting displays, sound effects, all as command / triggered as a response to identified actions of a first adult toy.] Generally speaking, an accessory device 209, if used, will be used in addition to a second adult toy 203 at the receiving system 201, but note that this is not required for this embodiment.

[0034] The adult toy 203 is once again generically represented; numeral 205 refers to one or more actuators of adult toy 203 which will take one or more automated actions, as commanded, while numeral 207 refers to one or more optional sensors used to report sensed data representing user manipulation of the second toy (e.g., much as was with the case for the embodiment of FIG. 1); note that the embodiment of FIG. 2 therefore optionally supports a two-way exchange, for example, both executing actions of adult toy 203 which are commanded in response to manipulations of a first adult toy (not seen in this FIG.) aswell as reporting data representing manipulation of the adult toy 203, which can be used to command reactions of the first adult toy or another device.

[0035] The system 201 receives commands which are optionally generated remotely, for example, by a transmitting system or a remote network system, which identifies actions / manipulation of a first adult toy and then identifies and commands reactions. Numeral 209 once again references a "lightning icon" to symbolically represent that scripted commands can be generated at a remote location. Note, however, that this is not required, i.e., numerals 209 and 211 and various dashed-line arrows appearing at the left of the FIG. indicated that, in this embodiment, sensor data interpretation can be performed and / or commands can be generated at any location in the network, including without limitation, as a direct part of system 101 (from FIG. 1), system 201, or at a server or cloud service in the Internet (e.g., as a function of coded software running on a computer, server, cloud business logic, etc.). As noted by numeral 213, configuration information, either learned / programmed locally or defined at a network level for complementary devices (e.g., a female toy linked / paired to one or more male toys) can be used to drive a translation function. Note again that no embodiment requires dissimilar first and second toys, e.g., some embodiments support use of the same toy at the transmitted end (e.g., toy 103 from FIG. 1) and at the receiving end (e.g., as toy 203), with actions commanded of toy 203 driven so to mimic sensed position / position change / manipulations of the toy (e.g., 103) used at the transmitting end.

[0036] Wherever command generation takes place, those commands are then executed, per numeral 215, to control the actuator of toy 203 and / or accessory 209. Note that this actuator need not be a motion transducer for all embodiments, e.g., it can include a lighting device, an auditory device, a pressure transducer, a fluid-driven device, or indeed, any other type of actuator, mechanical or otherwise. Per numeral 217, commands are optionally sent to a queue / scheduler, which in some embodiments is configured to insert a delay that is either programmed or dynamically-responsive to measured audiovisual buffering delays, for example, to cause commanded actions / reactions on toy 203 or accessory 209 to exactly align / synch with those manipulations on the transmitting end toy which are displayed and / or reflected in the rendered audiovisual signal. This delay can optionally be computed by a network service (e.g., by cloud business logic), with consequent programming and update of skew mitigation being a part of communication represented by with "lightning icon" 209; in other embodiments, it can also be computed and / or applied by a system associated with a first adult toy (e.g., system 101 from FIG. 1) or directly by system 201.

[0037] As referenced previously, in some embodiments, toy 203 can also include one or more sensors, with sampling / filtering / sync / delay estimations, 221, 223 225, similar to those introduced above in connection with FIG. 1 being provided for the reverse transmission direction (or to a different receiving toy or accessory). A communication connection between the toy 209 and system 201 can optionally provide for two-way or multichannel configuration, for example, via a wired or wireless link 219. As denoted in the FIG. by numeral 1 1 , sync and delay estimation 225 can optionally fed back to queue / scheduler 217 and used to adjust buffering delays / scheduling so as to exactly align audiovisual content with toy actions (i.e., for use in the forward and / or reverse transmission direction of an audiovisual signal); these functions can also optionally be provided remotely, for example, by a network or system associated with another system or adult toy (e.g., the system 101 from FIG. 1); this is once again denoted by a lightning icon 229.

[0038] FIG. 3 is an illustrative view of a hypothetical network 301. The network includes a first end, seen at the left of the FIG., which will be assumed to be transmitting sensor data as well as an audiovisual signal. The first end includes a first adult toy 309, a computer 313, a video camera (or other audiovisual device) 315, a router for Internet communications 319a, and software, represented abstractly by a floppydisk icon 335a. Note that many of these items are optional and / or are depicted separately simply to illustrate presence of these items, i.e., the audiovisual device is both optional and if present, may be optionally integrated with the depicted computer, as an embedded webcam. Similarly, some embodiments rely simply on a web-interface (e.g., with software implemented as business logic in the network and with no special software other than a browser resident on computer 313). Lines 317a and 333a denote that any depicted optional connection can be via a hardwire connection, but these or other connections can also be wireless, such as illustrated by dashed-line connections 333c, 333b and 317b, between the first adult toy and the router, between the computer and the depicted adult toy, between the audiovisual device and the router, and so forth - similarly, any depicted (optional) wired connection can instead be wireless (e.g., connections 317a and / or 333a can be wireless, for example Bluetooth, WiLAN, etc.). Note also that in some embodiments, the router 319a can be omitted and that functionality of associated with the computer can instead be integrated with the first adult toy 309 or resident on another device, e.g., such as a smart pad or cell phone.

[0039] Communications from the left side of the network are, in this embodiment, routed through a set of collocated or distributed network servers 305a-305c. From there, communications are routed to a second end of the network (i.e., the right side of the FIG.), represented by another computer 303, a secondadult toy 311, an optional audiovisual device 317, a router 319b and software executed by computer 303; as with software 335a seen at the left, this latter software is once again generically represented by a floppy disk icon 335c. For purposes of a basic description of functions, this second end is assumed to at least be receiving an audiovisual signal and commands for control of the second adult toy (or accessory 309), but it can also be transmitting sensor data and an audiovisual signal in the reverse direction, e.g., back to the first end of the network. As with the first end, any of the elements seen at the right hand side of the FIG. can optionally be omitted or combined with other depicted elements. The second adult toy 311 is depicted in this case as a male masterbator, but note that toys 309 and 311 can be any toys, whether of the same or different types, and whether or not from the same or different manufacturers; the depiction of a male masterbator in this case references that the two toys 309 and 311 can be complementary; for example, it should be assumed in this embodiment that is desired to command automated actions of the second adult toy 311 which are reciprocal to manipulations or actuations of the first adult toy 309. In the case of a live performance for example, a human performer streaming audiovisual content from the first end of the network to a customer at the second end of the network can, in synchronicity with captured audiovisual content, manipulate the first adult toy, for example, by moving it, stroking it, or using some other type of action; sensors on the first adult toy 309 are disposed so as to sense / capture these manipulations / actions. Sensor data is buffered and sampled / resampled at the first end of the network, to provide for a generic data stream, and then optionally conditioned and / or processed as appropriate, with information then being reported using a generic communication format (e.g., command / information format) to the servers 305a-305c; one or more of these servers perform optional translation in this embodiment under the auspices of depicted software 335b, resulting in commands for reactions which are to be sent to the second end of the network, specifically, to generate powered reactions in the second adult toy 311. As an example, each of the adult toy of the performer (toy 309) and the adult toy of the viewer (311) can be registered with the network as to type of toy and supported commands, and a translation file is then used to recognize performer manipulations and create scripted reactions in the second adult toy 311 - nearly any type of reaction supported by toy 311 can be generated, as desired, according to programming / mapping provided by the translation file. Again, as a hypothetical example, sensed stroking motion by the performer using toy 309 can be used to generate powered constrictions on toy 311 (e.g., using built-in actuators of toy 311). Note that translation to different types of actions are not required for all embodiments - for example, if toy 309 is a vibrator, it is entirely possible for a 'translation file' to specify actions / displacements of the second adult toy which example mimic similar actions / displacements sensed in the first adult toy 309. If supported by sensorspresent in toy 311 and if powered actuators are present in toy 309, customer manipulations of the second adult toy 311 can also be sensed, sent to the network, and used to trigger commanded actions / reactions in the reverse direction, that is, on the performer's toy 309. In this regard, some embodiments do not contemplate a broadcast service, e.g., it is contemplated that sessions can be initiated on an invitation basis or as part of a preestablished group, for example, between a remotely located, romantically involved couple. Note also that, as with any of the connections at the transmitting end, receiver-side connections can be wired or wireless using any known electronic, wired or wireless communication format.

[0040] FIG. 3 illustrates the use of three different servers 305a, 305b and 305c, each also being controlled in accordance with software (once again represented by the presence of a floppy disk icon 335b, denoting the presence of instructions on physical storage media). In this hypothetical example, server 305a is an audiovisual server, and establishes and manages content delivery, while server 305b is devoted to session initiation, management and termination, including functions of interpreting data from toy 309 and translating that data to commanded actions / reactions in toy 311 (and / or vice-versa), and server 305c is a business logic server, used for example for account management, authentication, payment clearance, and / or other functions, as desired. In alternate embodiments, greater or fewer numbers of server locations can be employed, with servers handling any combination of these (or other) functions. In this depicted case, software (e.g., 335b) causes circuitry (e.g., one or more processors of server 305b) to receive a request to initiate a new session between two specific individuals; note that some embodiments can support links between more than two individuals (such as by way of nonlimiting example, a performance in which video is streamed to a group of viewers, each receiving the same audiovisual content, but each having different toys that might be actuated in different ways according to respective translation files). The software and / or circuitry optionally obtains account / payment clearance to initiate a session, and communicates with servers 305a and 305b (via communication paths 307a / 307b) to open an audiovisual stream from audiovisual device 315 for viewing on computer 303; likewise, a return stream can also optionally be supported, e.g., from audiovisual device 327 (or computer 303) for display on computer 313. Streaming of content of this type typically uses well established Internet transport protocols, which buffer and retransmit packets and return acknowledgements, and which reorder potentially-out-of-order packets, to faithfully recreate content at a viewing device, but these technologies typically impose buffering delays endemic to these transmission and / or rendering processes. Conversely, interpretation of sensed toy manipulation data (from toy 309 or 311) and ensuing translation to commands for a second toy (or for multiple, potentially different second toys) typically involves different processing also with associated delays. In some embodiments, therefore these functions are split todifferent network machines, with some type of synchronization function applied to ensure proper alignment between device (toy) commands and displayed audiovisual material, as rendered, so as to preserve the time relationship between captured audiovisual materials and sensed performer toy manipulations in content / commanded reactions at the destination end.

[0041] An example would be helpful. A first human user, of first adult toy 309, initiates a session with a second human user, of second adult toy 311. It is assumed in this hypothetical that two-way video is supported, such that the second human user can see the first human user on computer 303, as captured by audiovisual device 315, and that the first human user can see on computer 313 the second human user, as captured by audiovisual device 327. Session establishment is communicated by server 305a or server 305b to computers 303 and 313, which initiate a video exchange via server 305a; if desired, this can be supported or facilitated a generic browser or through software 335a / 335c, e.g., via an application-specific viewer. Captured video from audiovisual device 315 is transmitted via path 317b to router 319a, and from there via path 321a to server 305a, which then routes video via path 323a to router 319b. Finally, audiovisual content is delivered via path 325a to computer 303, for rendering and display. Similarly, server 305b provides for receipt of sensed data representing use of toy 309 by the first human user; this data travels via path 333b or 333c to router 319a, and from there, via path 321b to server 305b; this latter server performs interpretation of actions of sensed toy data and 'translation' functions. In turn, server 305b transmits commands via path 323b to server 319b, and from there to computer 303 or directly to toy 311, for example, via one or more of paths 325a, 325b or 325c. As noted, in some embodiments, the computer 303 (or toy 311, if supported) can buffer / delay either video or commands for toy 311 so that, as commanded actions are taken, they appear synchronous with toy manipulations represented by audiovisual content as it is rendered on computer 303. Similarly, video captured by audiovisual device 327 is transmitted via paths 325a, 329a, 331a and 333a, routers 319a and 319b, and server 305a to computer 313, for rendering to the first human user. Sensed manipulations of toy 311 (i.e., by the second human user) are sent, via path 329b, to sever 305b where they are translated to actions / reactions that will be commanded of toy 309. These latter commands are sent via path 331b and one or more of paths 333a-333c to toy 309, where they likewise drive one or more actuators supported by that toy; here also, buffering / scheduling practices are used at computer 313 (or toy 309, if supported), so as to align the reverse direction audio / video with manipulations of toy 311, such that powered actions of toy 309 are synched with manipulations of toy 311 as represented in content rendered on computer 313. In this manner, the depicted system provides for an improved at each end of the depicted transmission scheme.

[0042] Note that some embodiments provide simply for stored audiovisual material (e.g., data stored on a physical storage medium), either with stream-embedded toy commands or with a separate track for a data stream representing first adult toy manipulations, or commands derived therefrom, and, optionally with data for synchronization. As represented by this statement, the techniques taught by this disclosure are not limited to live shows or contemporaneous transmission, e.g., it is possible to record a performance and sensed data representing synchronized use of a first adult toy, and then distribute that recorded content for optional, later playback of content with or without use of commands for a viewer's toy or accessory. Commands can electively be generated in advance and memorialized as part of the stored audiovisual product, or they can be later produced from stored a stored data stream representing performer (e.g., upstream) toy manipulations. Clearly, a number of variations to these principles can be applied, all of which are contemplated by this disclosure.

[0043] Also, note that use of a video server, command processing server and / or predetermined network midpoints are not required for any embodiment. In one example, a service can be configured as a virtual cloud service (e.g., using Amazon Web Services "AWS," or a similar service), while in another example, the system can be connected as a peer-to-peer system, e.g., with a transmitting end and a receiving end in a network communicating through ad-hoc network connection paths. It is possible to have sensor data translated to commands of another device either at the transmitting end, or the receiving end, or both.

[0044] FIG. 4 is a block diagram showing an embodiment 401 which provides for a session initiation function. Such an embodiment 401 can optionally be implemented at a server (such as server 305b from FIG. 3), but this is not required; further, any of the functions of FIG. 4 may be omitted from a particular implementation, if desired. Per numeral 403, code provided in connection with this embodiment can implement an account establishment / sign-in / registration or other security function; this function can further optionally include authentication and / or payment clearance functions, per numerals 405 and 407, as well as a configuration, definition or learning mode to associate a user's profile with any previously unknown toys or devices, per numeral 409. For example, if a particular user has a specific adult toy, a configuration routine can be employed to query the user to identify the particular toy; if the particular toy unknown to the system and / or the network, the configuration routine can employ further dialog activities that request further inputs from the user, or that request that the user perform certain actions of the toy and / or otherwise indicate toy capabilities. Advantageously, the system then automatically or solicitedly maps resources to driving actions associated with a performer's toy (e.g., possible positionalmanipulations of a performer vibrator), for example, assigning a buffer or register for each unique piece of sensor data that is to be received. Once the calibration routine is complete, type-specific device driving information can also be stored in either a public or private local library, for use in later sessions of the same user, e.g., as a device profile that can be selected to drive similar toys of other users. Device calibration / configuration will be further discussed below in connection with FIG. 9.

[0045] Numeral 411, denoting a session configuration function, refers to establishing / provisioning communication resources between a transmitting system and a receiving system, for example, allocating resources which will be used for management of network exchange of commands and / or data, for optional computation of network transmission delays, and transmitting / exchanging audiovisual content. As this statement implies, one embodiment provides an adult streaming service where a customer can select a show of a specific performer, either prerecorded or live, depending on embodiment, and then leverage other techniques provided by this disclosure. To this end, in association with session configuration 411, a customer can browse a library or catalog 413 of performances or performers in order to select a particular show to view / stream. Alternatively, per numeral 415, a session can be invitationbased, with a particular user sending a message through the service to a particular user contact (e.g., to the particular user's partner, using an invitation dialog) which, if accepted, will then link the accepting invitee into the specific session. Note that in other embodiments, these functions can be omitted, e.g., as referenced by numeral 417, a user can be referred to the service from a performer or other website, with this function then triggering the account establishment / sign-in / registration functions 403. Irrespective, as part of session configuration, the system / method then provisions communication resources, per numeral 412. For example, in the context of FIG. 3, discussed above, this provisioning might include messaging via paths 307a or 307b for a dedicated video or command processing server to establish buffers associated with the specific session; as part of this interchange, the system 401 can enable audiovisual streaming initiation 419 (e.g., by server 305a from FIG. 3) and command launch functions (e.g., by server 305b from FIG. 3), configuring these functions / servers to communicate with viewing user's application, machine or device (e.g., using an associated internet protocol (IP) address and port). As indicated by numeral 421, these functions can include identifying performer and viewer devices / accessories (specifically including device types), identifying any associated sensors and capabilities, and pre-loading a suitable translation file.

[0046] As an illustration, if it is known that a particular adult toy made by a specific manufacturer has four specific sensors, two actuators, and a specific signaling format (e.g., amplitude, command, etc.) forexternal transference of sensor data and / or actuator drive signals, then associated parameters can be identified and prestored parameters can be loaded and used to interpret (a) sensed data based on manipulation of an adult toy by a performer, (b) the monitoring of that data or changes in that data, to identify / interpret specific qualities or actions represented by that data, (c) the identification of specific actions that are to be taken as an automated response in a downstream toy or accessory, and (d) selection of and scheduling of commands for those actions including, as appropriate, any positional drive actions, amplitude, frequency or other settings, and commands for any supported non-motion parameters, for example pressure, suction, light, sound, and so forth. Note again that, by using the techniques discussed earlier, specifically, of buffering and resampling data from one or more sensors, arranged in one or more channels, and by reporting this data (e.g., to a server in one embodiment), techniques provided by this disclosure permit the linking and / or interaction with a wide variety of toys and accessories from different manufacturers.

[0047] Per numeral 423, the system also performs session administration functions. These can include the provision of group chat services between viewers or other session participants, help functions associated with use of the services, or other miscellaneous functions (e.g., tipping services from customer to performer). In this embodiment also, per numeral 425, buffering / transmission / rendering delays in either an audiovisual stream or a sensor data / command stream, or both, can be measured, quantified, and then used for synchronization between the two streams. In one contemplated implementation, delays can be computed simply based on Internet buffering and / or transmission delays, with a server continuously collecting delay information based on round trip packet travel time, acknowledgment receipt, metrics reported by a receiving device, time stamps, or using other conventional delaymeasurement protocols; in an ideal case, exact skew between the two streams as rendered is measured and then used to adjust stream timing to align with the slowest component, although this is not required for any embodiment. For example, in a contemplated case, IP routing delays are assumed to be the primary contributor to overall skew between the two streams, and delay computation and adjustment is based on this measured quantity alone; in other cases, delay can be measured at the time of rendering by computing the difference between two time stamps or indices (e.g., one for each stream) and optionally reporting this back to the server; in such an embodiment, it might be "good enough" to negate these delays specifically, that is, without addressing other sources of delay. Irrespective of the delay computation algorithm, in some cases, computed delay can be mitigated directly at the server, for example, by issuing commands for scheduled toy actions (e.g., scheduled in advance to mitigate video buffering delays), by delaying command issuance to mitigate delay, or in some other manner. In otherembodiments, the delay is computed by the network, but is transmitted to and applied at a receiving device, with toy commands and / or video being delayed relative to the other, so as to mitigate skew. When optionally combined with the techniques described above, especially the buffering and resampling data stream generation features, these techniques for a more effective and seamless implementation of haptics in the context of teledildonics and related services.

[0048] Finally, per numerals 427 and 429, the system also manages billing / payment and session termination functions. For example, although not required for all embodiments, one implementation supports a live or recorded broadcast from an adult performer where a customer optionally pays for one or more of access, duration and / or the ability to have toys automatically controlled responsive to performer-side toy manipulations, with the performer also optionally being compensated a portion of the customer payment for these activities; function 427 handles the associated monetary clearance, for example, optionally through server 305c from FIG. 3. When a session is ended, function 429 closes billing, and releases allocated video streaming and / or command processing resources, each as appropriate.

[0049] With overall network architecture and associated options thus understood, this disclosure will now more closely examine interpretation of sensor data in a first adult toy.III. INTERPRETING SENSOR DATA; COMMANDING (SYNCHED) (RE)ACTIONS OF A SECOND DEVICE.

[0050] FIG. 5 is a block diagram showing some techniques 501 for interpreting sensor data from an adult toy. FIG. 5 illustrates several basic functions, including: (1) a configuration function 503, used to identify and provision software with the capabilities of a driving adult toy (not shown), (2) a data acquisition function 511, where data is collected from a toy and sampled / resampled, to generate consistent stream data, and where further, optional processing is performed, to derive position, motion or other descriptions (e.g., offset, throw, rotation, etc.) and / or other parameters that can be used to describe a toy's manipulation, (3) a driving command preparation function 527, and (4) an optional skew computation and / or adjustment function 529. As denoted by numeral 533, one embodiment can take the form of a stored audiovisual product having associated sensor data processed in this manner, or resultant second device commands, for example, optionally stored as a combined stream or using a combined format some type, per numeral 535. In a different embodiment, as indicated by the use of 'lighting icon' 537, an output can consist of an sensor data and / or second device commands being transmitted to a remote destination (e.g., either with or without associated audiovisual content and / or stream synchronization information).

[0051] Expanding on this discussion, line 505 demarks offline-versus-online processes, with configuration being performed offline, that is, prior to the use of and / or recording of actions of a first adult toy as part of a session or stream generation. This is to say, configuration information can be first learned or loaded, per numeral 503, that will be used to configure later monitoring processes and interpretation processes to perform as desired. In this regard, the configuration information can be used to identify any or all of: (1) type of toy, or manufacturer, or model number, (2) a number of sensors, (3) type of each sensor, for each sensor, (4) identification of an affiliated motion or action being sensed, (5) range of variation, and / or amplitude, and / or (6) an optional algorithm or mapping between one or more sensors and data which is to be quantified or reported to a network. For example, a hypothetical adult toy might include six sensors including three to sense positional displacement and three to sense rotation in each of three axes; information representing this data might be relayed to the network as raw position data, or alternative, as polar coordinates, or in some other fashion, all as desired for the specific implementation or in view of actions / reactions that are to be commanded by a second device. A different hypothetical toy might employ four sensors to collectively sense (and sample / resample) throw (amplitude) of a thrusting device, or later displacement associated with a stroker, with this data being reported in the same or a different manner. As denoted by dashed-line block 507, the sensors can optionally represent multiple, independent degrees of freedom of the toy being monitored. The configuration information in these cases can be used by a transmitting end system, in one embodiment, to establish six buffers or four buffers, matching the number of sensors for each example. Alternatively, if what is to be tracked is a derived quantity, for example, frequency, velocity, acceleration, or some other parameter, it might be appropriate to configure software to use a processing formula which combines values sampled / resampled from buffers, for each sensor, to develop an aggregated measure, for example, reporting a parameter based on outputs of multiple sensors or based on a recursive algorithm (e.g., based on a time based history of samples). The configuration information is advantageously structured such that transmitting end software can sample data from the toy and produce a generic data stream, as discussed previously, i.e., at a defined rate that is independent of toy type or manufacturer, for each sensor that is to be monitored; configuration of a local system then further permits that system to record / report desired information, so as to trigger desired actions / reactions of a second toy. Note again that it is not required that the sensors be associated with any specific powered capability of the toy being monitored.

[0052] Space below line 505 is associated with "online" processes, that is, where it is assumed that the toy is in use and that actions / manipulations are actively being monitored and are the subject ofreported, resampled sensor data. In this embodiment, as part of an exemplary data acquisition process 511, data from sensors, for example, as updated in buffer(s) 512, is sampled / resampled at a constant rate, per numeral 513; it is then processed in this embodiment for motion estimation 515. To perform this motion estimation, the system processes the data stream produced through sampling using noise reduction 517, DC level estimation 519, zero crossing detection 521, and frequency estimation 523 blocks and / or using processing pertinent to any other desired parameterization, per numeral 525. In this regard, in one contemplated implementation, the sensor data stream represents position information in a degree of freedom; as noted, it is typically desired to locally process this sensor data to derive information about estimated current actions / manipulations of the toy being monitored; data in buffer(s) 512 is continuously updated and is resampled at a defined rate, for example, twenty times per second, with this resampled digital data then being filtered so as to removed noise and to identify a DC level. [The term "DC level" refers to the average sensor reading over a period of time, for example, over the last 100 data samples, and the DC level is used in some embodiments to derive information about throw / magnitude as well as frequency estimation.] This is to say, with a DC level being established, the samples can be processed to detect each time the sampled sensor value (or a combined value based on weighting or combining multiple sensors) crosses the DC value, with frequency of motion then being inferred from these detected crossings; this information represents estimated motion. Generalizing these processing steps, the local system can perform this - or any desired analogous processing - to derive information not only about current position, but also information such as velocity, offset or throw, instantaneous frequency and other parameters that can describe toy motion and / or manipulation by the human user.

[0053] In one specifically-contemplated case, software processes motion in each sensed degree of freedom by identifying a normalized measure of relative position, and then by further processing a timewindow of samples to identify a movement frequency and amplitude; the processing software then reports data in two alternate forms, e.g., as normalized position data, in the event that frequency falls below a threshold, and as a current estimate frequency and amplitude, in the event that frequency falls above that threshold. As this example indicates, "raw" data reported by a transmitting end of the network can take a number of different forms, all as optionally established by configuration information. This is to say, in one embodiment, software is configured to simply report data for each sensor according to this algorithm (e.g., as a manufacturer-agnostic form of data expression).

[0054] Naturally, these examples are illustrative, and other embodiments can detect other types of data and / or parameters, for example, rotation, pressure, suction, and other parameters. This informationcan then be used to identify actions of the monitored toy and to drive commands for actions / reactions of a second toy, as referenced by function block 527, for example, as programmatically-specified by a translation file 528. Note that each of these elements is represented in dashed-line to connote its optional nature, e.g., it is possible to simply output the captured data stream, or any other associated parameterization, per numerals 533, 535 and 537, with motion interpretation, translation and / or command generation occurring either locally or in a later, downstream system or operation. Similarly, video synchronization functions 529 are also optionally implemented as part of embodiment 501, in a downstream system or process, or both; in an implementation where audiovisual material is to be streamed, indices can optionally be inserted into the output data as appropriate, for example, time stamp information, a video frame identifier or bookmark, or some other information, to provide information to locate a place in the audiovisual stream that matches specific sensor data. As noted earlier, and per function block 539, in one embodiment, video and command transport can optionally be output together, with synchronization information if desired, for dynamic network transmission or for later storage / rendering.

[0055] FIG. 6 is another block diagram relating to processing of sensor data. FIG. 6 shows detailed processes that are used in one embodiment of a system which can optionally be distributed across multiple network locations. Data in buffers 603 can also optionally represent multiple sensors, corresponding to the same or multiple degrees of freedom, as represented by numeral 604. As with the embodiment just discussed, this data - as updated from the toy being monitored - is then sampled / resampled at a defined, toy-manufacturer-agnostic rate, to produce a generic data stream per block 605; per block 607, in one implementation, this rate is 20 times per second for each sensor and / or buffer. Sampled / resampled data is then processed per block 609, with exemplary optional processing including filtering, scaling, averaging, calculating a mean or weighted combination of some type, gamma correction, or other desired functions, as desired, all as represented by numeral 611. As indicated by numerals 613 and 615, processing parameters can be specified according to optional, predefined configuration information, and this configuration information can also optionally used to specify sampling and / or buffering parameters. In one contemplated implementation, as once again represented in a dashed-line block (block 617), the output of this process can be position data for the adult toy being monitored, optionally already scaled (by the processing function 609) to normalize reported data in a manner conducive to driving actions of a potentially unknown downstream device (and potentially a variety of different downstream devices). This data is then processed for noise reduction, per numeral 619; as indicated by dashed-line block 621, in one embodiment, a recursive linear filter is used to smoothvariation reported by the numerous samples, specifically in one case, a second-order biquad filter. The position data of course can be reported directly to a network or stored, as mentioned previously, but optionally, this data can also be processed locally to estimate motion, for example, by calculating instantaneous frequency, amplitude and / or other parameters such as velocity, acceleration, etc. (e.g., any of the other parameters mentioned herein). To this end, for example, an optional zero-crossing (DC crossing) detector 623 and frequency-estimation block 625 can be applied to obtain a motion estimate , as just described. Per numeral 627, positional data can be processed / interpreted to facility drive command preparation, for transmission downstream, in any desired format; for example, as indicated by dashed-line block 629, a reported format can consist of a record / payload which identifies a device [ld(x)], a channel corresponding to a specific degree of freedom and / or sensor, e.g., [Chfy)], a position (e.g., "50") and a speed (e.g., "100"). Per block 630, the reported data can take an alternative format if desired, for example, an identifier for device [ld(x)], channel corresponding to a specific degree of freedom (e.g., throw or position, e.g., [Ch(y)]), a frequency (e.g., "F=25hz") and an amplitude (e.g., "A=10"), with the output format optionally changing based on data in the stream satisfying satisfies a threshold, as previously referenced. Of course, each format is illustrative only and can take any form useful to a specific implementation, and / or represent any desired property, as textually represented by options block 631. As previously noted, this payload can also include an indice used for stream timing synchronization, for example, a time stamp or other value, per numeral 633. Irrespective of payload format, the depicted system then outputs data / parameters being monitored, optionally in a packetized, encrypted format, for transmission over a network.

[0056] Note again that many or all of the functions represented in these examples can be embodied as software, that is, as instructions on one or more physical storage mediums that, when executed, will cause circuitry (e.g., one or more processors) to operate as a special purpose machine and to execute the some or all of the described functions; this is to say, one form of the techniques presented herein is a software application that can be downloaded to a laptop, server, or combination of these things, and be used to interact with a monitored adult toy, irrespective of whether the toy and / or system hardware (e.g., circuitry) elements are provided with or separately from such software.

[0057] FIG. 7 is a block diagram of one embodiment 701 that receives "standardized" sensor / motion data and responsively generates commands to actuate a second device; the techniques depicted in FIG. 7 are optionally executed at the network level, e.g., by software installed on one or more servers.

[0058] As before, sensor data can be received as a result of monitoring manipulations of a first adult toy, as indicated by an offline data block 703. If this incoming data is received in a packetized format, e.g., over a WAN such as the Internet, it is decrypted (as appropriate) and disassembled, per numeral 705, to recover its payload; that payload optionally can have the format specified by boxes 629-630 from FIG. 6, but this is not required for any embodiment. With the payload recovered, data representing position, actuation or other parameters is buffered and monitored. As indicated by function block 707, this monitoring performs functions of: testing for recognition of defined actions; when a defined action is recognized, as specified by a translation file 709, identifying a consequent reaction that is to be triggered in a downstream "second" device (e.g., a toy or an accessory); and then, using the command format specific to the toy / accessory being driven (or client software resident on a downstream, receiving end), commanding the consequent action. These functions may be combined and / or coded together, and they can also be represented as discrete software modules. To perform these functions, resources (e.g., network level resource) associated with processing the specific sensed data / reaction stream accesses the translation file(s) specific to the session of interest; if multiple different downstream devices are to be actuated, a separate translation file can be provided for each and used to map actions of a common (e.g., "performer") first adult toy manipulations to respective, different actions of multiple downstream toys (or accessories), as desired, and as specified by the pertinent translation files. For example, in a hypothetical case where a performer uses a stroking device as the upstream adult toy, the translation functions might be coded so as to identify a frequency and an amplitude, either based on a single payload or monitoring of multiple payloads; received data is tested against conditions specified in the pertinent translation file (e.g., one for each different type of downstream toy or accessory). For a situation where a downstream toy is a power-driven male masterbator, a first translation file might be configured to specify constriction which is displaced along a longitudinal axis of the male masterbator while, by contrast, in situations where a downstream toy is a vibrator, a second translation file might be configured to, in parallel, respond to the reported frequency and amplitude by issuing commands to the vibrator for corresponding changes in motion. Naturally, these hypotheticals represent illustrative examples only, and many variations and implementations of these techniques will occur to those having ordinary skill in the art. As denoted by numeral 712, each translation file can be drawn from a local or virtual library kept for a multitude of clients and / or device types, indexed either by a session or client identifier or by an ID linked to sending and receiving device type. If the embodiment is implemented at a network level, then as alluded to by function block 713, any resultant commands can be issued / transmitted via a network to a downstream "second" device. If there are multiple actuators associated with a single downstream toy,then separate channels (and optionally separate command queues) can be used to communicate with the respective actuators of that single downstream toy; if there are multiple different devices (e.g., toys / accessories) that are to be driven with a reaction, a separate command queue can optionally be established for each one, for example, configured with pertinent IP address and / port and stream identifier to address commands to the respective destination.

[0059] With commands identified and queued for each pertinent downstream device and / or channel, then as appropriate, commands are encrypted and packetized and configured for IP transport, prior to being transmitted to the pertinent receiving system or device, as indicated by numerals 712, 713, and 714.

[0060] The embodiment of FIG. 7 also references optional support for skew mitigation, with mitigation being applied by the embodiment of FIG. 7, at the receiving end of a network session, or both; these functions are generally represented in FIG. 7 by numerals 717, 719, 721, 723, 724 and 725. First, if a indice (e.g., time stamp) was provided with incoming sensor data, per numeral 721, then that indice can be used for delay calculation. As referenced by numeral 717, in one embodiment, transmission delays are measured by the embodiment of FIG. 7 based on acknowledgments received as a reply to packet transmission to a receiving system; these acknowledgements, for example, can be used to provide an indication of transmission and / or buffering delays, and these delays in turn can optionally factored into the queuing and / or command process, for example, by specifying an execution time for outgoing commands (e.g., relative to the associated inbound time stamp). Note that this is only one possible skew measurement mitigation compensation mechanism, and that many possible mechanisms for compensating for skew exist. As another alternative, delay can be calculated per numeral 719 and transmitted to the pertinent receiving system or downstream device, as referenced by numeral 725.

[0061] FIG. 8 shows an embodiment 801 associated with a given receiving system. As indicated by offline data block 803, inbound commands for action / reaction by a downstream device (toy or accessory) are optionally received from a server, with decryption and packet disassembly once again being performed, as indicated by function block 805. Each command is queued / scheduled 807 by the receiving system (or toy) for issuance to the pertinent actuator, toy, accessory or otherwise as appropriate. For a situation where the particular receiving system comprises an application installed on a generic computer or other smart device (e.g., cell phone), connection to a particular toy or accessory is frequently by Bluetooth communication, using a manufacturer-specific command structure which is used by amanufacturer-provided software application; in such a case, the command structure, as encoded into the translation file (see FIG. 7) is advantageously configured so as to directly communicate with the software application using the manufacturer's own command structure, e.g., with a local, manufacturer-agnostic client-side application associated with the network emulating this manufacturer-specific command structure. Alternatively, either the network, or a client-side application (e.g., associated with a service which links a transmitting-side user with a receiving-side user) can communicate with the device by issuing commands to the manufacturer-specific application, which in turn directly issues Bluetooth commands recognized by the toy. In yet another contemplated implementation, a local software application configures the downstream toy or accessory to be "Internet ready," e.g., in much that same way that a smart appliance is configured to a home network, with the device or toy being configured for Internet access, with the device or toy being registered so as to be recognized by a server or service, and with commands from the network once again being preconfigured for direct transmission to the toy. Clearly, many communication protocols exist, and it is within the ordinary level of skill for a toy designer or software designer to select a pertinent protocol to enable external control of a given 'smart' toy or accessory.

[0062] As noted earlier, skew mitigation can advantageously also be implemented at the receiving system. Per numeral 809, in one embodiment, transmission delays (e.g., packet buffering delays or routing delays) can be calculated by the server and reported to the device (or receiver-side software); these values can optionally be added to any receiver side video rendering delays and used to calculate an aggregate delay or offset, which is then factored in to scheduling / execution of device commands, per numeral 811. If device commands are accompanied by an indice or time stamp, this can be used by the receiving system to directly calculate delay, e.g., as indicated by function blocks 813, 815, 817 and 819. This is to say, a command time or indice is compared to a matching indice or time stamp of queued content, with the command then being launched or scheduled for execution using timing selected so as to offset measured audiovisual delays. It is also possible to apply skew in the opposite direction, e.g., if the content precedes a matching stream of toy / accessory actuation commands, the video can be buffered and otherwise queued / scheduled, so as to better align with matching commands. With command and video properly aligned, each is issued to the corresponding device (video buffer, toy, accessory, etc.) and / or executed for simultaneous rendering and effect, per numeral 821.IV. CONFIGURATION.

[0063] FIG. 9 shows an embodiment 901 for calibrating a system and / or software to interact with a potentially unknown adult toy or accessory having either actuators (which can be externally commanded) or sensors for sending data representing user manipulations. As with other embodiments discussed herein, this embodiment can optionally be embodied as instructions stored on a physical storage medium, e.g., as a software module for performing calibration. As referenced by numerals 903 and 904, a user optionally downloads a software application to his or her computer or other smart device, and is asked to create an account or otherwise log in. The software is coded so as to interrogate a local network (e.g., Bluetooth or LAN connection) and determine device identity or, alternatively, is coded so as to directly connect a device to the Internet for communication with a predetermined web interface, per numeral 905. If the result of this automatic interrogation yields a specific device is associated with a known ID (for example, identifying a specific toy or accessory from a known manufacturer, for which configuration information already exists), pertinent information can be retrieved by interrogating a library of known configurations and retrieving and / or downloading pertinent configuration information, per numeral 907. Optionally, a human user can be directly queried to manually enter in or indicate specific toy type, manufacturer identity, model number, etc., to retrieve a known configuration. An identified configuration can be tried or tested, with a user confirming success. If a suitable configuration is found, that configuration can then be stored at network level in associated with the user account (or alternatively, configured in the local client software application), per numeral 909. However, if no existing configuration has yet been found, the software routine can then issue a series of scripted commands and / or requests for user manipulation (e.g., via a user interface), with the software then attempting to intercept sensor data arriving via Bluetooth (or via a USB connection), or with the user confirming toy / accessory command response, each as appropriate. The software is coded to progress through as list of scripted actions and / or user instructions in order to identify device characteristics and capabilities (i.e., in terms of sensors present and / or available actuators), and to either select a best-matching known device profile or create a custom profile for the particular toy and / or accessory. Optionally, as indicated by numeral 912, in the case of a 'smart' toy, controllable via another software application, for example, the user can be instructed to command various types of actions with corresponding Bluetooth commands being intercepted and learned for later emulation in concert with the techniques discussed earlier, e.g., for use with a translation file. In the case of sensor data, as represented by numeral 911, the software advantageously records / measures / monitors data variation as a function of user instructions, and develops suitable scaling and / or weighting factors, with a test function being employed to verify acceptability to the user of anyselected configuration, per numeral 913. Optionally, as part of this process, a user is permitted to scale or change data interpretations or scripted responses, for example, adjusting a frequency or amplitude of via a graphical user interface presented by the software, per numeral 915. Finally, the routine ends, with updating of the user profile and / or application, as appropriate, and optionally with a server-level library entry created which can then be selected by the individual user (and / or other users). The result of this configuration function is that device capabilities are expressed in a standardized format, useable as an interface for interpreting sensor data and / or issuing commands to the device, per numeral 919. Taking a simplified nonlimiting example, if the device is a Bluetooth controllable light or lamp, the software can issue a number of commands with the user being requested to indicate when the light or lamp turns on or off, flashes, changes color and so forth, with a suitable configuration scripting then being created to permit remote control of the lamp; if the device is one which produces sensor data, for example, a particular adult toy, the user can be requested to take specific actions / use specific motions, with the software monitoring intercepted, resampled sensor data (e.g., received by wire or Bluetooth) to determine which incoming information represents each pertinent capability; naturally by extension, these same interrogation methods can be applied to any type of adult toy or accessory.V. EXAMPLE OF SENSOR DATA PROCESSING.

[0064] FIGS. 10A-10D are used to narrate discussion of an example of processing sensor data. As mentioned previously, in one embodiment, data from a first adult toy is buffered and resampled at a manufacturer-agnostic rate, with a resulting generic data stream then being used to detect user manipulations. As represented by numeral 1001 in FIG. 10A, resampled sensor data with respect to time can be expected to be time-varying (i.e., either digital or analog values depending on sensor type). While this data is assumed to represent position or motion in this discussion, the techniques provided by this disclosure are not so limited, and monitored data can (once again) represent any desired quantity or parameter, such as rotation, displacement, extension, position, offset, pressure, time, or indeed, any other value. As referenced previously, data is advantageously resampled at a standard rate, e.g., twenty times per second, and optionally scaled, thereby obviating the need to a manufacturer-specific command integration. The resampled data is processed by a filter, for example, a linear filter, to remove noise, thereby smoothing the signal, as referenced by numeral 1011 in FIG. 10B. This data is then processed in this embodiment to identify a DC level, which is represented by horizontal line 1023 (relative to resampled sensor data signal 1011) in FIG. 10C. The DC value can be calculated simply as a running average of a window of samples (e.g., an average of the last 256 samples). Per FIG. 10D, the sensor data signal 1011is then processed to identify DC level crossings, as each demarked by a vertical line 1033 in FIG. 10D. [The term zero-crossing is also used here, and should be understood to refer to the crossing of a time-varying signal with a normalized reference, whether or not "zero."] These crossings are then used to identify frequency, e.g., with the software then calculating a reporting sensor data consisting of a frequency (e.g., corresponding to lines 1033) and an amplitude, e.g., denoted by current maximum amplitude, such as referenced by bracket 1035.

[0065] Note that this processing example is non-limiting, e.g., any desired processing can be applied as desired, including by way of non-limiting example, recursive models, models which combine data from multiple sensors, computation of polynomials, and so forth, as a model for detected manipulations. In one embodiment, as indicated earlier, position data can be measured and converted to frequency an amplitude, with a mixed-format being reported depending on whether movement exceeds a defined threshold. Any reported value can be expressed as a color, intensity, position, angle, frequency, acceleration, velocity or rate, pressure, level, amplitude, offset or displacement, vector, or indeed, any desired parameterization.VI. FURTHER CONSIDERATIONS.

[0066] As should be apparent, the features discussed above facilitate the virtual linking of two adult toys (or an adult toy and an accessory), in a manner where manipulations or actions of one adult toy are monitored, based on generic data streams produced from sensor data, and in a manner where actions or reactions can be commanded based on monitored data or the actions / manipulations they represent. While this type of connection conventionally might require that software be configured specifically to only interact with a known, matched pair of devices (e.g., from the same manufacturer and / or using a matching data reporting / command issuance protocol) the present techniques provide for facilitated connection and interaction with a much greater range of toys and / or accessories, in a manner compatible with, or complementary to, any manufacturer-provided control software.

[0067] As should further be apparent, the techniques provided by this disclosure can be used to script actions / reactions as desired by the programmer and / or as desired by a specific user, e.g., the detected action / manipulation of one toy (e.g., a stroking action) can be translated so as to trigger a color change in a light accessory, a specific vibration pattern in a vibrator, or other actions, as desired. FIG. 11 shows an exemplary set 1101 of complementary links that can be formed between a transmitting device 1103 (e.g., a first adult toy in a transmitting system) and a receiving device 1105 (e.g., a second device,such as a second adult toy and / or an accessory). This listing is meant to be non-limiting and additional pairings and / or action / reaction types will naturally occur to those having ordinary skill in the art.VII. CONCLUSION.

[0068] As noted earlier, it is specifically contemplated that any of the foregoing elements may be mixed and matched regardless of whether or not used called out in a dedicated example highlighted discussed above or single FIG. For example, one embodiment provides a system which is used to interface with an adult toy having sensors and generate, from sampled / resampled sensor data information, which can be used to drive commanded actions of a second device; such a system, employing techniques introduced by this disclosure, can be used / distributed and or sold independently of other networked components, for example, a service or a receiving device, and regardless of whether or not techniques are applied to synch data and / or actions with associated audio or video. Yet another embodiment features a network-level service which can be implemented independently of toys, software or accessories which might be supplied by a third party. Similarly, as noted earlier, yet another embodiment can take the form of recorded media, having integrated and / or synched commands intended for an adult toy or accessory, wherein techniques introduced by this are used to create and / or structure the recorded media. Many variations of the techniques and elements described above, and their combination, will occur to those having skill in the art, whether or not specifically called out above, which nevertheless are within the spirit and scope of this disclosure.

[0069] Without limiting the foregoing, this disclosure contemplates subject matter represented by or similar to the content of the following clauses, on a nonlimiting basis:

[0070] Techniques which rely on or employ resampling of sensor data from an adult toy, e.g., to produce a data stream;

[0071] Techniques which calculate an audio or video buffering delay (or other transmission delay) which then are applied locally or downstream to synch actions of an adult toy or related accessory with live or recorded audiovisual material;

[0072] Techniques for generating media (e.g., recorded or streamed) with commands for controlling an adult toy and / or related accessories which are indexed to or otherwise synched with the recorded media, or where command issuance is otherwise scheduled and / or delayed for use with the generated media, e.g., in a manner adjusted for transmission, buffering orother delays;

[0073] Techniques for controlling a downstream user device or audiovisual rendering consistent with the foregoing, for example, where techniques are used to align the toy and / or accessory with streamed or stored audiovisual media;

[0074] Techniques where multiple translation files or mappings are used to interpret sensor data from a first adult toy, and to generate commands for transmission to or use by multiple different downstream adult toys or accessories, e.g., where the actions / reactions can also be different;

[0075] Techniques where a system employs a configuration routine to learn capabilities of an adult toy through scripted actions and monitoring of generate sensor data, e.g., with consequent generation of a configuration file;

[0076] Use of a zero crossing detector and frequency estimation to generate standardized motion signals representing a set of predefined motion types or manipulation actions of a first adult toy (e.g., not necessarily related to automated electronic capabilities of the adult toy);

[0077] Use of a mixed data reporting format for sensed toy data, e.g., position for a degree of freedom where motion falls below a threshold and frequency / amplitude for motion which is greater than the threshold;

[0078] Techniques where resampled data representing manipulation of a first toy are used to drive actions of a second (or an accessory);

[0079] A recorded storage media consistent with any of the foregoing;

[0080] A service bureau consistent with any of the foregoing, including without limitation, a live streaming service, optionally used by professional performers, which streams or distributes performer shows to one or more customers of the service or of the performer;

[0081] An adult toy consistent with any of the foregoing;

[0082] Software, embodied as a downloadable application or otherwise, for use at atransmitting end, a receiving end, or as a mid-network processing end, consistent with any of the foregoing; and

[0083] Other techniques which use any combination / permutation of the foregoing.

[0084] As mentioned, this listing is nonlimiting, and it is contemplated that any of the elements / particulars of the systems or embodiments described herein can be mixed and matched in any desired order, permutation or combination. Advantages of such order, permutation or combination will be apparent to those having ordinary skill in the art.

[0085] It should therefore be appreciated that by providing techniques which address definite needs in the field of teledildonics and adult services, specifically, for readily extending services to and / or interfacing with toys or accessories of various manufacturers, and in facilitating ability to link actions of a second device (e.g., toy or accessory) to monitored actions / manipulation of a first toy.

[0086] The foregoing description and in the accompanying drawings, specific terminology and drawing symbols have been set forth to provide a thorough understanding of the disclosed embodiments. In some instances, the terminology and symbols may imply specific details that are not required to practice those embodiments. The terms "exemplary" and "embodiment" are used to express an example, not a preference or requirement.

[0087] Various modifications and changes may be made to the embodiments presented herein without departing from the broader spirit and scope of the disclosure. Features or aspects of any of the embodiments may be applied, at least where practicable, in combination with any other of the embodiments or in place of counterpart features or aspects thereof. Accordingly, the features of the various embodiments are not intended to be exclusive relative to one another, and the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMS.We claim:

1. (Original) A system comprising: a buffer to intermittently receive sensor data representing updated information associated with actuation of the first adult toy in at least one degree of freedom; and circuitry operable to: sample content of the buffer at a predetermined rate, to obtain data samples, wherein the predetermined rate is independent of a rate at which the sensor data is intermittently updated in the buffer; generate a sequence of packets for transmission to a remote destination via a wide area network (WAN), wherein a payload of the sequence of packets is dependent on the data samples; and transmit the packets in the sequence to the remote destination.

2. (Original) The system of claim 1 wherein the system further comprises instructions stored on at least one physical storage medium and wherein the circuitry comprises at least one microprocessor, wherein the instructions, when executed, are to control operation of the at least one microprocessor so as to perform the sampling of the content of the buffer, the processing of the data samples, the generation of the sequence of packets, and the transmission of the packets.

3. (Original) The system of claim 1 wherein: the circuitry is further operable to process the data samples to identify a position of the first adult toy and a motion of the first adult toy; and the payload of the sequence of the patents is effective to convey the motion of the first adult toy.

4. (Original) The system of claim 1 wherein the circuitry is further operable to process the data samples to: identify an amplitude associated with the motion and DC level associated with variation in the amplitude; detect crossings of the DC level by the amplitude with respect to time; andidentify a frequency of the motion as a function of a rate of the detected crossings.

5. (Original) The system of claim 1 wherein the circuitry is further operable to store an identifier associated with the first adult toy and to format the packets in the sequence to include the identifier.

6. (Original) The system of claim 1 wherein the circuitry is further operable to encrypt a payload of the packets in the sequence, such that the packets in the sequence represent encrypted information.

7. (Original) The system of claim 1 wherein: the sequence of packets is a first sequence of first packets and the remote destination is a first remote destination; the system further comprises circuitry operable to: store an internet protocol (IP) address associated with a second device; access a mapping, wherein the mapping identifies one or more reactions to be performed by a second device as a function of the payload; generate a second sequence of second packets for transmission to a second remote destination, the second remote destination being associated with the IP address, the sequence of second packets describing the one or more reactions to be performed by the second device; and transmit the second sequence of second packets to the second remote destination.

8. (Original) The system of claim 7 wherein the second device is a second adult toy which has at least one powered actuator and wherein the second sequence of second packets comprise one or more commands for the powered actuator of the second adult toy to execute at least one of a motion pattern, a light pattern, a sound pattern or a pressure pattern as part of the one or more reactions.

9. (Original) The system of claim 7 wherein: the second sequence of second packets is to be received by the second remote destination in association with at least one of an audio signal or a video signal also to be received at the second remote destination, the at least one of the audio signal or the video signal to be rendered at the second remote destination in association with the one or more commanded reactions; andthe system further comprises circuitry operable to calculate a value associated with delay of the at least one of the audio signal or the video signal relative to the one or more commended reactions.

10. (Original) The system of claim 9 wherein the system further comprises circuitry to transmit the value to the second remote destination, the second remote destination to delay execution of the one or more reactions according to the value, such that the rendering of the at least one of the audio signal or the video signal is synchronized with the one or more reactions, notwithstanding the delay of the at least one of the audio signal or the video signal.

11. (Original) The system of claim 9 wherein the system further comprises circuitry to schedule the one or more reactions according to the value, such that the rendering of the at least one of the audio signal or the video signal is synchronized with the one or more reactions, , notwithstanding the delay of the at least one of the audio signal or the video signal.

12. (Original) The system of claim 1 wherein the circuitry is further operable to process the data samples by applying a linear filter to the data samples, and wherein the payload of the sequence of packets is dependent on an output of the linear filter.

13. (Original) The system of claim 1 wherein the buffer is a first buffer, wherein the sensor data is first sensor data, and wherein: the system further comprises a second buffer to intermittently receive from the first adult toy second sensor data representing updated second information associated with actuation of the first adult toy in the at least one degree of freedom; the circuitry is further operable to: sample content of the second buffer at a predetermined rate, to obtain second data samples, wherein the predetermined rate at which the content of the second buffer is sampled is independent of a rate at which the second sensor data is intermittently updated in the second buffer; and the payload of the sequence of packets is also dependent on the second data samples.

14. (Original) The system of claim 1 wherein the predetermined rate is constant with respect to time and is at least five samples per second.

15. (Original) The system of claim 1 wherein at least one stream, of an audio stream or a video stream, associated with the actuation of the first adult toy, is to be played at a rendering destination, and wherein the circuitry is operable to receive an index associated with the at least one stream and is to insert stream alignment information into the sequence of packets, the stream alignment information adapted to permit synchronization of a timing associated with the payload with playing of the at least one stream at the rendering destination.

16. (Original) The system of claim 1 wherein the circuitry is further operable to estimate motion of the first adult toy and wherein the payload comprises estimated motion of the first adult toy.

17. (Original) The system of claim 1 wherein the first adult toy comprises a specific toy model from a specific toy manufacturer, wherein the system comprises a software application adapted for execution on at least one of a mobile device or a computer, wherein further: the software application is operable to cause at least one processor to convey to a human user of the first adult toy, via a user interface, specific instructions for actuating the first adult toy according to a predetermined sequence, in association with a configuration mode; and the software application comprises instructions operable to cause at least one processor to configure the circuitry to process the sensor data; the configuration in dependence on sensor data received from the first adult toy in association with the predetermined sequence.

18. (Original) The system of claim 1 wherein the first adult toy comprises a specific toy model from a specific toy manufacturer, wherein the system comprises a software application adapted for execution on at least one of a mobile device or a computer, wherein further: the software application is operable to cause at least one processor to convey to a human user of the first adult toy, via a user interface, specific instructions for actuating the first adult toy according to a predetermined sequence, in association with a configuration mode; and the software application comprises instructions operable to cause at least one processor to transmit, to the remote destination, a unique identifier associated with the first adult toy.

19. (Original) The system of claim 1 wherein the first adult toy comprises a specific toy model from a specific toy manufacturer, wherein the circuitry comprises at least one processor, wherein the system comprises a software application adapted for execution by the at least one processor, wherein further: the software application is operable to cause at least one processor to discover identity of the specific toy model; and the software application is operable to cause at least one processor to format the packets in the sequence to include the identity.

20. (Original) An apparatus comprising instructions stored on at least one physical storage medium, the instructions, when executed operable to cause at least one processor to: intermittently receive, from a first adult toy, sensor data representing updated information associated with actuation of the first adult toy in at least one degree of freedom, and store the receive sensor data in a buffer; sample content of the buffer at a predetermined rate, to obtain data samples, wherein the predetermined rate is independent of a rate at which the sensor data is intermittently updated in the buffer; generate a sequence of packets for transmission to a remote destination via a wide area network (WAN), wherein a payload of the sequence of packets is dependent on the data samples; and transmit the packets to the remote destination.

Images