Apparatuses, methods and systems for an interactive proximity display tether with remote co-play

APPARATUSES, METHODS AND SYSTEMS FOR AN INTERACTIVE PROXIMITY DISPLAY JETHER WITH REMOTE CO-PLAY

RELATED APPLICATIONS

[o ooi] Applicant hereby claims priority under 35 USC §119 for United States provisional patent application serial no. 61/151,832 filed on February⁷ 11, 2009, entitled "APPARATUSES, METHODS AND SYSTEMS FOR REMOTE INTERACTIVE REALTIME CO-PLAY," attorney docket no. 19626-004PV. [ 0002] The entire contents of the aforementioned applications are herein expressly incorporated by reference.

FIELD

[0003] The present invention is directed generally to an apparatuses, methods, and systems of interactive display, and more particularly, to APPARATUSES, METHODS AND SYSTEMS FOR AN INTERACTIVE PROXIMITY DISPLAY TETHER WITH REMOTE CO-PLAY.

BACKGROUND

[ 0004] Portable game environments such as the Nintendo Gameboy, Nintendo DS, Sony PSP, and mobile communications handsets such as the iPhone, Palm, Blackberry and/or other devices allow users to engage in gaming in a mobile fashion. These devices 1 typically have screens of portable dimension and allow users to engage in gaming on the

2 go.

3 SUMMARY

4 f o O O 5 ] The APPARATUSES, M ETI IODS AND SYSTEMS FOR AN INTERACTIVE

5 PROXIMITY DISPLAY TETHER WITH REMOTE CO-PIAY (hereinafter "CO-PLAY") 8 provides an interactive cooperative gameplay ("co-play") platform that allows multiple ? users to operate an application, e.g., in game environments. For example, a CO-PLAY

8 facilitates a first iPhone user to participate in or "co-play" in the golf game with a

9 second iPhone user on the same gaming platform. In another implementation, the first0 iPhone user may tether with a display device for larger visualization - i.e., avatars1 representing the first and second players may be transferred to the display device and2 updated based on the user manipulations of the first and second iPhones in a real-time3 manner, respectively. 4 [0006] In one implementation, the CO-PLAY enables users to view on a remotes device, gameplay for gaming applications receiving input from multiple mobile device(s).6 The users may manipulate the mobile devices, engage and/or stimulate device sensors,7 and/or the like and watch the results one or more target remote display(s). The CO-8 PLAY thus expands the possibilities for mobile device applications, gameplay, and/or9 the like by allowing the user to simultaneously manipulate the mobile devices and view0 the results without the need to constantly check the mobile device display. In one1 implementation, a mobile device equipped with one or more motion-sensors may be2 used to play a game, such as golf or bowling, and the RCD interface may allow the user 1 to view the gameplay on a remote display as they swing the mobile device to control the

2 gameplay.

3 [0007] In some implementations, a user may use CO-PLAY to facilitate remote

4 display between a first and a second mobile device. Furthermore, depending on the

5 particular implementation, the Co-play IPDT may establish and maintain a persistent

6 remote display platform across first and second mobile devices. In another example, a

7 first mobile device initiates a tennis application with a second mobile device. The first β device establishes and maintains a communication link to facilitate generating a 9 persistent platform as a tennis court on both mobile devices. In an implementation, the0 users of the first and second mobile devices, manipulate the device to control the tennis1 player on the commonly displayed persistent tennis court. In another implementation,2 the users respective devices establish and maintain the common platform, but provide a3 unique perspective for display on a target device that displaying the data associated with4 the manipulations of the respective devices. 5 BRIEF DESCRIPTION OF THE DRAWINGS 6 [0008] The accompanying appendices and/or drawings illustrate various non-7 limiting, example, inventive aspects in accordance with the present disclosure: 8 [0009] FIGURE 1 is of a block diagram illustrating an overview of an9 implementation of data flows between AN INTERACTIVE PROXIMITY DISPLAY0 TETHER WITH REMOTE CO-PLAY (hereinafter "CO-PLAY") system and affiliated1 entities in one embodiment of the CO-PLAY operation; 2 [0010] FIGURE 2 provides an implementation of IPDT system components in one embodiment of the CO-PLAY operation;

[oo i i] FIGURES 3A-C provides logic flow diagrams and examples of screenshots illustrating aspects of interactive proximity display tethering within embodiments of the CO-PLAY operation;

[0012] FIGURE 4 provide block diagrams illustrating examples of data formats of interactive proximity display tethering within embodiments of the CO-PLAY operation;

[0013] FIGURE 5A-5D illustrate example configurations of an interactive proximity display tether with co-play within one embodiment of the CO-PLAY operation;

[0014] FIGURE 6A-6B provide logic flow diagrams illustrating aspects of real- time co-play within embodiments of the CO-PLAY operation;

[0015] FIGURE 7A-7B provide logic flow diagrams illustrating aspects of real- time co-play in alternative embodiments of the CO-PLAY operation;

[0016] FIGURE 8A-F provide example screen shots illustrating aspects of the CO- PIJVY within embodiments of the CO-PLAY operation;

[0017] FIGURE 9A-C provide example diagrams and screen shots illustrating aspects of the CO-PLAY within embodiments of the CO-PLAY operation;

[0018] FIGURE 10 illustrates implementations of an IPDT housing configured as a golf club in one embodiment of the CO-PLAY operation; and

[0019] FIGURE 11 is of a block diagram illustrating embodiments of the CO-PLAY controller; [0020] The leading number of each reference number within the drawings indicates the figure in which that reference number is introduced and/or detailed. As such, a detailed discussion of reference number ioi would be found and/or introduced in Figure i. Reference number 201 is introduced in Figure 2, etc.

DETAILED DESCRIPTION

CO PLAY [OO 21] This disclosure details the implementation of APPARATUSES, MElTHODS AND SYSTEMS EOR AN INTERACTIVE PROXIMITY DISPLAY TETHER WITH REMOTE CO-PLAY (hereinafter "CO-PlAY"). CO-PLAY implements an interactive application at a user handset to tether with a target device and/or another user handset whereby users may project a local screen running a gaming application on the handsets to a larger display device.

[0022] For example, in one embodiment, CO-PLAY may be implemented on various mobile devices, such as on a smart phone platform, e.g. Apple's iPhone OS, Google's Android OS, Microsoft's Windows Mobile, Blackberry's OS, and/or the like. In one embodiment, a user operating such a mobile device may select to play with a CO- PLAY gaming application from his/her mobile device, e.g. an iGolf game, etc. If the user launch the CO-PLAY application, for example, by clicking a CO-PLAY enabled application and/or component icon from the mobile device screen menu, the mobile device may query for available target devices within a local area network. For instance, in one implementation, the mobile device may search for a laptop, a desktop, a projector, a television, and/or the like that are registered within a Wi-Fi, Bluetooth, etc. range. The user may then be provided a list of search results of available target device and may enter a selection. In one implementation, the user may choose a television, and the mobile device may establish a communication channel and tether with the television. In one implementation, the gaming screen on the mobile device may be projected to a larger display of the television, which allows the user to operate the mobile device as a remote game controller while the video gaming screen is displayed in a real-time and interactive manner on the television.

[ 0023] For another example, in one implementation, a user operating a first mobile device may select to co-play a game with a second user operating a second mobile device, e.g., an iTennis application. In that case, the first device may establish and maintain a communication link to facilitate generating a persistent platform connection as a tennis court on both mobile devices. In one implementation, the users of the first and second mobile devices, manipulate the device to control the tennis player on the commonly displayed persistent tennis court. In another implementation, the users respective devices establish and maintain the common platform, but provide a unique perspective for display on a target device that displaying the data associated with the manipulations of the respective devices.

[ 0024] In one embodiment, a method is disclosed, comprising: receiving a request to initialize an interactive co-play component; querying for co-play client devices; providing a list of available co-play client devices based on the query; obtaining a selection of a co-play client device; configuring a communications channel for the selected co-play client device; and instantiating the interactive co-play component through the communications channel.

[ 0025] FIGURE 1 is of a block diagram illustrating an overview of an implementation of data flows between a CO-PLAY system and affiliated entities in one embodiment of the CO-PLAY operation. In Figure 1, a user (or users) iO5a/b operating a source device lioa/b, a target device 120 with a remote display 125, a CO-PLAY 1 database 119, a gaming server 130, and a system administrator 140 are shown to interact

2 via a communication network 113.

3 [ 0026 J In one embodiment, a user 105a may operate with a source device 110a to

4 connect to and share a screen of the source display 115 of the source device with a

5 remote display 125 of a target device 120. The source device 110a may include a wide

6 variety of different devices and technologies such as, but not limited to mobile devices,

7 dedicated game handsets, general computing devices, and/or the like. The target

8 devices 120 may include devices and technologies such as mobile handsets, dedicated

9 game handsets, general computing devices, game consoles, set top boxes, cable boxes,

10 video displays, and/or the like. For example, as illustrated in Figure 1, in one

11 implementation, the source device 110a may be a portable handset, such an Apple Inc.

12 iPhone, while the target device 120 may be a computer with a display screen 125. For

13 another example, the source device 110a may be a mobile device such as an Apple

14 iPhone secured in a housing shaped as a gaming implement, such as a golf club for a golf

15 game (as will be further illustrated in one implementation in Figure 8), tennis racket for

16 tennis game, fishing pole for a fishing game, baseball bat for a baseball game, and/or the

17 like.

18 [0027] The CO-PLAY facilitates connections through the communication network

19 113 based on a broad range of protocols that include WiFi, Bluetooth, 3G cellular,

20 Ethernet, physical tethers (e.g., iPhone Video AV to Dock Connector Cable, which allows

21 for connection to a monitor or TV), and/or the like. In one embodiment, the

22 communication network 113 may be the Internet, a Wide Area Network (WAN), a

23 telephony network, a Local Area Network (LAN), a Peer-to-Peer (P2P) connection, 1 and/or the like. In one embodiment, the source device no may detect, handshake and

2 interact with the target device 120 to exchange control information and data payloads

3 via the communication network 113, as will be further illustrate in one implementation

4 in Figure 4. For example, in one implementation, the communication network 113

5 provides a communications path such that the source device 110 may project its source

6 display 115 onto the target device remote display 125 one of which may also open the

7 communication path to another source device nob. In this manner, a relatively small

8 source device may drive a larger display on a target display, as well as communication

9 with one or more client devices, allowing for tethered and interactive control by the

10 source device using the remote display 125.

11 [0028] In another embodiment, the CO-PLAY may implement an interactive

12 control scheme that allows for the interactive control of games by one or more source

13 devices iioa/b via the larger remote display 125 of the target device 120. For example,

14 in one implementation, a user 105a may co-play a gaming application displayed at the

15 target device with another user 105b. In this manner, the source device 110a may be

16 configured to query and communicate with another source device nob as a client device,

17 as will be further illustrated in one implementation in Figures 5A-5D.

18 [0029] In one embodiment, the CO-PLAY entities such as the source device 110,

19 the target device 120 and/or the like, may also communicate with a CO-PLAY database

20 119. In some embodiments, distributed CO-PLAY databases may be integrated in-house

21 with the target device 120, and/or the source devices iioa/b. In other embodiments, the

22 CO-PLAY entities may access a remote CO-PLAY database 119 via the communication

23 network 113. In one embodiment, the CO-PLAY entities may send data to the database 1 119 for storage, such as, but not limited to user account information, application data,

2 protocol data, application history, and/or the like.

³ [0030] In one embodiment, the CO-PLAY database 119 may be one or more

4 online database connected to a variety of vendors, such as hardware vendors (e.g. Apple

5 Inc. , Intel, Sony, etc.), gaming application vendors (e.g. Nintendo, Game Cube, Game

6 Boy, etc.) , service vendors (e.g. PlayStation Network, WiiConnect24, etc.) and/or the

7 like, and obtain updated hardware driver information, new gaming application packages

8 and services from such vendors. In one embodiment, the source device 110 and/or the

9 target device 120 may constantly, intermittently, and/or periodically download updates,0 such as updated user profile, updated software programs, updated command1 instructions, and/or the like, from the CO-PIAY database 119 via a variety of connection2 protocols, such as Telnet FTP, HTTP transfer, P2P transmission and/or the like. 3 [0031] In a further embodiment, the target device 120 and the source device 1104 may connect to an online gaming server 130 via the communication network 113. For5 example, in one implementation, users iO5a/b may employ source devices lioa/b to6 join an Internet game community (e.g. F.A.S.T., etc.) at an online gaming server 130,7 which is locally displayed at the target device 120. 8 [0032] In one embodiment, a system administrator 140 may communicate with9 the CO-PLAY entities for regular maintenance, service failure, system updates, database0 renewal, security surveillance and/or the like via the communication network 113. For1 example, in one implementation, the system administrator may be a user, who may2 directly operate with the target device 120 to configure system settings, parental control, and/or the like. In another implementation, the system administrator may be a service vendor for Internet gaming.

[0033] FIGURE 2 illustrates an implementation of CO-PLAY system components in one embodiment of CO-PLAY operation. A CO-PLAY device 201 may contain a number of functional modules and/or data stores. A CO-PLAY controller 205 may serv e a central role in some embodiments of CO-PLAY operation, serving to orchestrate the reception, generation, and distribution of data and/or instructions to, from and between target device(s) and/or client device(s) via CO-PIJAY modules and in some instances mediating communications with external entities and systems.

[0034] In one embodiment, the CO-PLAY controller 205 may be housed separately from other modules and/or databases within the CO-PLAY system, while in another embodiment, some or all of the other modules and/or databases may be housed within and/or configured as part of the CO-PLAY controller. Further detail regarding implementations of CO-PLAY controller operations, modules, and databases is provided below.

[0035] In one embodiment, the CO-PLAY Controller 205 may be coupled to one or more interface components and/or modules. In one embodiment, the CO-PLAY Controller may be coupled to a user interface (UI) 210, a maintenance interface 212, and a power interface 214. The user interface 210 may be configured to receive user inputs and display application states and/or other outputs. The UI may, for example, allow a user to adjust CO-PLAY system settings, select communication methods and/or protocols, initiate a remote display mode, engage mobile device application features, identify possible target/client device(s) and/or the like. In one implementation, the user 1 interface 210 may include, but not limited to devices such as, keyboard(s), mouse,

2 stylus(es), touch screen(s), digital display(s), and/or the like. In one embodiment, the

3 maintenance interface 212 may, for example, configure regular inspection and repairs,

4 receive system upgrade data, report system behaviors, and/or the like, In one

5 embodiment, the power interface 214 may, for example, connect the CO-PLAY

6 controlled 205 to an embedded battery and/or an external power source.

? [ O O 36] In one embodiment, the CO-PLAY Controller may further be coupled to an β applications engine 260, configured to run device application software. In one 9 implementation, the applications engine 260 may receive sensory input information

10 originating from one or more integrated sensors and interpret the information to update

11 the configuration of an application state. In an implementation the updated application

12 state data may be transferred to a target, client and/or source device depending on the

13 implementation for display. For example, an application run by the applications engine

14 may comprise a video game, such as may be controlled via a motion-sensitive mobile

15 device, which uses CO-PLAY to establish a communications channel with a laptop,

16 configured in turn, to display transferred video game data.

17 [0037] In one implementation, the CO-PLAY Controller 205 may further be

18 coupled to a sensor module 220, configured to interface with and/or process signals

19 from sensor input/output (I/O) components 225. The sensor I/O components 225 may

20 be stimulated by user manipulation, environmental conditions, and/or the like to

21 generate electrical signals that may be received and/or processed by the sensor module

22 220 and/or other CO-PLAY components, which in turn act to generate input controls

23 which can be used by the application. A wide variety of different sensors may be 1 compatible with CO-PLAY operation and may be integrated with sensor I/O

2 components 225, such as but not limited to transducers, accelerometers, thermometers,

3 anemometers, barometers, microphones, and/or the like, configured to measure states

4 of motion, sound level, volume, pitch, pressure, wind speed, temperature, data transfer

5 rate, light intensity level, position, elevation, weather, moisture level, humidity, and/or e the like. In one implementation, the sensor module 220 may configure signals received 7 from the sensor I/O components 225 in a form suitable for an application being run by β the applications engine 260. In another implementation, the applications engine 260 9 may receive signals directly from sensor I/O components 225 for processing to update0 an application state for one or more running applications. For example, in one1 implementation, a user may engage a CO-PLAY remote control device housing in a golf2 club (as will be further illustrated in one implementation in Figure 8). The user may3 swing the remote control device as if swinging a real golf club in field, and the sensor4 I/O 225 may detect signals of the motion of the club and transfer the signals (e.g.5 electrical pulses from accelerometers indicating a velocity and a direction of a swing, etc.)6 suitable to the sensor module 220. The sensor module 220 may process and analyze the7 received signals and generate data describing characteristics of the movement, e.g.s direction of the movement, speed of the movement, motion level, etc., and transmit the9 data to the CO-PLAY controller 205. For example, in one embodiment, the iPhone SDK0 toolkit and/or runtime libraries may be installed and/or used to access and interpret1 such actions. 2 [0038] In one embodiment, the CO-PLAY Controller 205 may further be coupled3 to a communications module 230, configured to interface with and/or process signals4 from communications I/O components 235. The communications I/O components 235 1 may comprise components facilitating transmission of electronic communications via a

2 variety of different communication protocols and/or formats as coordinated with and/or

3 by the communications module 230. Communication I/O components 240 may, for

4 example, contain ports, slots, antennas, amplifiers, and/or the like to facilitate

5 transmission of display instructions, such as may instruct a remote display what and/or

6 how to display aspects of a mobile device application state, via any of the

7 aforementioned methods. Communication protocols and/or formats for which the

8 communications module 230 and/or communications IO components 235 may be

9 compatible may include, but are not limited to, GSM, GPRS, W-CDMA, CDMA,

10 CDMA2000, HSDPA, Ethernet, WiFi, Bluetooth, USB, and/or the like. In various

11 implementations, the communication I/O 235 may, for example, serve to configure data 1? into application, transport, network, media access control, and/or physical layer formats

13 in accordance with a network transmission protocol, such as, but not limited to FTP,

14 TCP/IP, SMTP, Short Message Peer-to-Peer (SMPP) and/or the like. The

15 communications module 230 and communications I/O 235 may further be configurable

16 to implement and/or translate Wireless Application Protocol (WAP), VoIP and/or the

17 like data formats and/or protocols. The communications I/O 235 may further house

18 one or more ports, jacks, antennas, and/or the like to facilitate wired and/or wireless

19 communications with and/or within the CO-PLAY system. For instance, in the above

20 example, the CO-PLAY controller 205 may transmit the received sensor data

21 characteristics of the movement of the controller device to the communication module

22 230, and the data may then be transmitted to external entities (e.g. the target device,

23 etc.) through the communications I/O 235.

24 [0039] Numerous data transfer protocols may also be employed as CO-PLAY 1 connections, for example, TCP/IP and/or higher protocols such as HTTP post, FTP put

2 commands, and/ or the like. In one implementation, the communications module 230

3 may comprise web server software equipped to configure application state data for

4 publication on the World Wide Web. Published application state data may, in one

5 implementation, be represented as an integrated video, animation, rich internet

6 application, and/or the like configured in accordance with a multimedia plug-in such as

7 Adobe Flash. In another implementation, the communications module 230 may β comprise remote access software, such as Citrix, Virtual Network Computing (VNC), 9 and/or the like equipped to configure application state data for viewing on a remote0 client (e.g., a remote display device). 1 [0040] In one implementation, the CO-PLAY controller 205 may further be2 coupled to a plurality of databases configured to store and maintain CO-PLAY data. An3 applications database 240 may contain application data, user IDs, settings,4 configurations, saved games, game states, application interface elements, and/or the5 like. A protocols database 245 may include data pertaining to communication protocols6 and/or data configurations suitable for publication on the World Wide Web, sharing? between client and server devices in a remote-access software setup, and/or the like. A8 user database 250 may contain information pertaining to account information, contact9 information, profile information, identities of hardware devices, Customer Premise0 Equipments (CPEs), and/or the like associated with users, application history, system1 configurations, and/or the like. A hardware database 245 may contain information2 pertaining to hardware devices with which the CO-PLAY system may communicate,3 such as but not limited to user devices, display devices, target devices, Email servers,4 user telephony devices, CPEs, gateways, routers, user terminals, and/or the like. The hardware database 228 may specify transmission protocols, data formats, and/or the like suitable for communicating with hardware devices employed by any of a variety of CO-PLAY affiliated entities.

[0041] In one embodiment, the CO-PLAY databases may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. For example, in one implementation, the XML for the User Profile in the user database 250 may take a form similar to the following example: <User> <Quasi static info> <User ID>12Ϊ 4b 6789</User ID> <Hardware ID> SDAS P¹K₄ b65? 1 Phone i,0 </Hardware ΪD> <Census info^ John Smith; 123 Maple Dr , Smalltown, CA 92676; (123)456 7890; ]sraith5>enail.coiii; 55 years; male; white; married; 2 children; etc. </Census m£o>

</Quasi-static mfo> <Dynamic mfo> <Application history> <Last logm> <Server ID> US-CA-ADD00089 </Server ID> <Time> 19:33:25 08^30-2009 </Time>

</Last logm>

</AppliCdtion history> </Dynamic mfo> </User> [0042] FIGURE 3A is of a logic flow diagram illustrating aspects of interactive proximity display tethering within embodiments of the CO-PLAY operation. In one embodiment, a user wishing to tether a remote display may engage an application that is 1 implemented with a CO-PLAY component. In an implementation, the CO-PLAY

2 component may be implemented as a software development kit (SDK) and/or as an

3 object library that may be included in any application where a CO-PLAY may be useful.

4 In one embodiment, any program that incorporates the CO-PLAY component may

5 become available and/or downloaded and installed on a source device, where a user will

6 have the option to run the CO-PLAY application 300, and a user may submit request to

7 initialize the CO-PLAY application 302. For example, in one implementation, a user

8 may initialize a "remote game control" application from a CO-PLAY mobile device by

9 selecting a CO-PLAY icon from the iPhone menu, and enter a CO-PLAY gaming

10 application, as illustrated in one implementation in screen 870 of Figure 3D. Once the

11 application is selected and begins its instantiation, the CO-PLAY component may query

12 for tether targets where the source device may search for appropriate tether devices via

13 all of its communication channels 310, as illustrated in one implementation in screen

14 372 of Figure 3D. In one embodiment, the CO-PLAY component may search for

15 available target devices within a local area network based on the registered devices

16 and/or communications channels in the source devices communication stack in the

17 hardware database, and/or based on zero configuration protocols, and/or based on user

18 submitted target information, as will be further illustrated in Figure 3B.

19 [0043] In one embodiment, the source device may then provide the user with a

20 list of potential tether targets 330 from which the user may make a selection 335, as

21 illustrated in one implementation in screen 373 of Figure 3D. Upon selecting a target

22 device, the source device may then connect with the selected tether target 340 based on

23 the type of the tether target 340, as illustrated in one implementation in screens 375 and

24 378 of Figure 3D and will be further illustrated in Figure 3C. Once the CO-PLAY is 1 established, the CO- PIvV Y may attempt to incorporate additional clients to facilitate CO-

2 PLAY 365, otherwise the source and target devices may proceed with the CO-PLAY 367

3 (as illustrated in one implementation in screen 380 of Figure 3D). This type of CO-

4 PLAY may be extended to facilitate Co-play CO-PLAY as described below in the example

5 implementations of Figures 5A-5D wherein target devices assume Server responsibilities

6 for the illustrated Co-play CO-PLAY implementations.

? [0044] Figure 3B illustrates aspects of querying for tether targets within

8 embodiments of the CO-PLAY operation. In one embodiment, if a user submit an

9 indication of target device 315, the CO-PLAY may search for target device based on the0 user submitted information 316. For example, in one implementation, a user may enter1 the known IP address, MAC address, acronym, hardware label, digital signature, driver2 certificate, zero-configuration information, and/or the like of a target device via a3 mobile device, and the mobile device may search within an available range of a local4 area network for the corresponding indications. Otherwise, if there is no user submitted5 indications, the CO-PLAY may determine whether to query the communication stack in6 the hardware database 318. For example, in one implementation, the CO-PLAY may7 display a message to a user and receive an indication from the user to determine8 whether to query the database. If yes, the CO-PLAY may form a query on the9 communication stack for registered devices/communication channels that are0 compatible with the source device 320. Otherwise, if not, the CO-PLAY may start a1 search to locate suitable target devices within a range of local area network by zero2 configuration protocols 322, such as, but not limited to Service Location Protocol (SLP),3 Universal Plug and Play (UPnP), Jini, Bluetooth Service Discovery Protocol, WS-4 Discovery, Proprietary Discovery Protocol, Bonjour and/or the like. [0045] In ^one embodiment, the tether target device may broadcast its availability and publish a server via a zero-configuration network, e.g. an Apple SDK may create Bonjour service. For example, in one implementation, the C++ implementation based on Bonjour for creating a service and publishing the tether target may take a form similar to: / / Creat i ng the Bon] our Servi ce

CFNetService netService = CFNetServiceCreate (NULL, CFSTRf"") , type, name, port) ;

// Publishing the Server

void init (CFNetServiceRef netService) { CFStreamError error; CFNetServiceClientContext context -- { 0, NULL, NULL, NULL, NULL } ;

CFNetServiceSetClient (netService, regiscerCallback, &context) ; CFNetServiceScheduleWithRunLoop (netService , CFRunLoopGetCurrent ( ) , kCFRunLoopCommonModes) ; CFNetServiceRegister (netService , NULL) ; if i CFNetServi ceRegi ster (netService , terror) ■=.= false) { CFNetServiceUnscheduleFromRunLoop (netService , CFRunLoopGetCurrent () .kCFRunLoopCommonModes) ; CFNetServiceSetClient (netService, NULL, NULL) ; CFRelease (netService) ; } }

[OO46]

[0047] For another example, the C/C++ implementation based on Proprietary Discovery Protocol for creating a service and broadcasting service information as a tether target, may take a form similar to: //Broadcast Service Information

SOCKET sock; sock = socket (AF INET, SOCK_DGRAM, 0) ;

char broadcast = ' 1 ' ;

int sres - setsockopt (sock, SCL SOCKET, SO BROADCAST, &broadcast , sizeof (broadcast )

if (sres < 0)

{ closesockpt ( sock) ; return 0,

}

struct sockaddr in re CV ;

mt len - sizeof (struct sockaddr in) ;

char msgU ="C0- PLAY PC Vl .01" ;

recv.sin family = AF_ INET; recv .sir. port = htons (MYPORT) ; recv.srn addr.s addr = INADDR BROADCAST;

sendto (sock, sendMSG, strlen(msg) +1,0, (sockaddr *) &recv, sizeof (recv) ) ;

[0048] In one embodiment, if such query returns a null result 315, the CO-PLAY may display a message to the user indicating the search is unsuccessful, and may proceed with 310 upon user request. If the query returns at least one result 315, the CO- PLAY may generate a list of available target devices 325, and proceed with 330.

[0049] Figure 3C illustrates aspects of connecting with tether target within embodiments of the CO-PLAY operation. The CO-PLAY may determine whether the target is a physical tether 342. If the target device is connected via a physical tether 342, for example, a direct audio/video connection such as an iPhone Video AV to Dock Connector Cable that is plugged directly into a large television, then the CO-PLAY application may begin communicating data associated with the display of the source device 344 to the larger remote display device via the physical tether, and the application may continue to execute taking advantage of a larger display 349. In an alternative embodiment, the physical tether may be a Casio XJ-S57 with a WiFi YW-2 adapter connected via WiFi. In one embodiment, the source device may transmit data to the target device through the physical tether in a variety of formats, such as, but not limited to Component VideoS-Video, HDMI, VGA, DVI, DisplayPort and/or the like.

[ 0050] In one embodiment, if the target is not a physical tether 342, the CO-PLAY may determine whether the target is a processor-based device/entity 350. IF not, the CO-PLAY may display a message to the user indicating the tether is unsuccessful and proceed with 330 upon user request. In one implementation, If the remote device is a processor based device 350, the source device may discern if the target device is capable of executing complementary application code as the remote device - for example: if the remote device is running a distributed object oriented application 351, if the remote device is running a web server 352, if the remote device is running a remote display client (e.g., citrix, VNC, etc.) 353, or a web browser 354. As already discussed, if the device is broadcasting based on a zero-configuration protocol (e.g. Bonjour, SLP, UPnP, Jini, Bluetooth Service Discovery Protocol, WS-Discovery, Proprietary Discovery Protocol, and/or the like) or responding to a proprietary communication request, , then the tether target is processor-based, ¹ [ 0051] In one embodiment, if the target computer is running a web browser 354,

2 the source device may run a web server. For example, if the source device is an iPhone

3 running UNIX, an Apache information server may be made part of the CO-PLAY

4 component, and that information server may be instantiated. At that point, the source

5 device can provide an IP address and/or register itself via zero configure network

6 protocols like Bonjour, and a user may use the web browser on the target machine to

7 navigate to the web server on the source device. In one embodiment, an iPhone would

8 be the source device and run an Apache web server, and a user at a target device, e.g., an

9 laptop, would navigate to the IP address of the web server on the iPhone over a WiFi0 connection. At this point a custom communication channel has been established1 between the source and target devices 347, and the source device may provide2 instructions via its web server to instantiate the remote target, e.g., provide applications3 executable by the target web browser 348. At this point, the source application may4 engage the CO-PLAY application 349 and use the custom application channel as a5 conduit to render its source display onto the remote display. For example, the source6 device web server may have a Java and or Flash applet that it will provide to the target? device which provides the target device with the capability of remote display viewing.8 As another example, a TightVNC Java View^rer applet may be downloaded by the target9 web browser from the remote iPhone Apache web server and instantiated with0 configuration (e.g., with the IP address, set user/password keys, etc.) to connect to a1 VNC server that has been launched on the source device. In this manner, the target2 devices web browser becomes the remote display for the source device. In one3 embodiment, the source devices web server may instruct the target devices web browser 1 to expand its window to the full size of the screen, thus providing an enlarged viewing

2 area effectively mirroring the display on the source device.

3 [0052] In one embodiment, if the target device already has a remote desktop

4 sharing component 353 such as Visual Network Computing (VNC), Apple's remote

5 display technology reachable via Bonjour, and/or the like, the user may be prompted

6 with a screen instructing them on what to enter on the target device to complete the ? connection (e.g., IP address, user/password, help to access proper areas of the operating

8 system, etc.) and configure a custom communications channel 347. In one embodiment,

9 the source device will launch a VNC server as part of the CO-PLAY component which0 will be viewable in the shared area of the Apple OS X Finder application, and may be1 selected for screen sharing, thereby instantiating the remote target 348 to project the2 source device's display to the target. At this point, the CO-PIAY application may3 continue to execute 349. For example, in one implementation, a C++ implementation4 for an iPhone to connect to a service based on Bonjour may take a form similar to: 5 // Connecting to a Service 6 7 NSNetService *service; 8 NSInputStream *istream = nil; 9 NSOutputStream *ostream = nil; 0 1 [service getlnputStream: &istreatn outputStream: &ostream] ; 2 if (istream && ostream) 3 { 4 / / ... 5 } 6 [ O O 53 ] [0054] In ^one embodiment, if the target device is running either a custom application 351 and/or web server configured to communicate with source devices 352, the source device has a number of channels over which it may communicate. In the case of distributed object oriented application, object oriented method calls may be sent to the target application to establish a connection. These custom applications may employ similar remote display technologies as already discussed. In another embodiment, where a source application uses a graphics rendering engine such as Open GL, Flash, and/or Apple's OS X development SDK, where such graphics libraries scale depending on a devices display abilities, the source device may be used as an input device, and the target device may run a more robust version of CO-PLAY application stored on the source device. [0055] The more robust version of the CO-PLAY application may be provided to the target device in a number of ways. In one embodiment, the CO-PLAY source application has a directory having multiple versions of the application, and may transfer more elaborate versions to the target device. In another embodiment, the CO-PLAY source application will have a web link and have the target device automatically download the more elaborate applet and/or application and have that installed and instantiated. Upon the instantiation of the target version of the CO-PLAY application, the source CO-PLAY application will provide only user input signals which will be sent via the communication channel 347 to the instantiated remote target where the remote application will interpret those instructions 348 and execute the application in a more robust manner. For example, a game using an iPhone as a controller, e.g., iGolf, may have a more robust version of iGolf loaded on a target laptop, and as such, take the 1 acceleronieter inputs of an iPhonc source device to direct the execution of the game on

2 the target device.

3 [ 0056] In one embodiment, when IPDT application is engaged, the source device

4 may transmit control information and data payloads to the target device in a variety of

5 data formats. FIGURE 4 illustrates examples of data formats transmitted from the

6 source device to the target device within embodiments of the IPDT operation. In one

7 implementation, the source device may send data to a processor-based target device via

8 a binary data packet 402, which includes fields such as message type 405, sequence

9 number 406 acknowledgement number 407, data offset 408, data length 409, checksum

10 410, options 411 and data payload 412 and/or the like. The data 412 may include, but not

11 limited to accelerometer information, pointer coordinates (pressing on the screen),

12 images, GPS information, user information, and/or the like. For example, in one

13 implementation, the data 412 may take a form similar to, a 64-byte user information

14 field, including user ID, device ID etc., a 96-byte accelerometer information, including

15 3-dimentional coordinates (x,y,z), a 64-byte latitude/longitude value, a 64-byte pointer

16 coordinate value (x,y), a 32-byte image length value, and data with variable lengths

17 such as image raw data, video time information, and/or the like. In one embodiment,

18 the image raw data may be generated and sent in compliance with the VNC video

19 transport data format and/or a pointer to separate VNC video transport data stream. In

20 one embodiment, the pointer may point to a .vnc file on the file system, or may

21 incorporate the contents of such a file such that it specifies host, port, password, options

22 (e.g., bit depth, mouse settings, scale, emulation, clipboard, etc.), and extensions such

23 as sessions. In one embodiment, Remote Framebuffer Protocol (RFB) may be used as

24 may be seen in: The Remote Framebuffer Protocol, Tristan Richardson (RealVNC Ltd), October 26, 2009, <img file="WO2010093831A1_D0001.tif" /> and at Display Filter Reference: Virtual Network Computing<img file="WO2010093831A1_D0002.tif" /> both of which are hereby expressly incorporated by reference.

[0057] In another implementation, the source device and the target device may exchange data via a Common Object Request Broker Architecture (CORBA 420) mechanism. For example, the source device and the target device may define a series of objects, such as, but not limited to accelerometer which may contain information regarding accelerometer status, GPS which may contain information about the device location, pointer which contains information about the user interaction on the screen, screen which contains the screen stream, and/or other data structure which may contain various data streams and constructs pertaining to a given application. In one implementation, the source device 422 as a host may interface with object structure 425, object Class Structure 427 running on an object requested broker 429, and communicate with client target 445 via a network connection 430. The client target may implement a specified object 440, object skeleton code 437 running on the target device side object requested broker 435. For example, in one implementation, the C++ implementation for defining data object under CORBA may take a form similar to the following: //Define Accelerometer Data Object class AccelerometerDataService : public PortableServer : : RefCountServantBase { public: AccelerometerDataService () ; virtual -AccelerometerDataService () ; virtual CORBA: : Boolean Update ( CORBA: : Long x, CORBA: :Longy, CORBA : : Lonqz ) } ;

COPBA: : Boolean Acre leromsiterDataService : : Update ( CORBA : : Long x , CORBA: : Long y, CORBA : : Long z ) {

return true; }

[0058] In one example, the C++ implementation for connecting to the server under CORBA may take a form similar to the following: //Connecting to the Server

C0RBA_0RB_var orb -CORBA_^ORB imt (argc , argv) ; const char* refFile "AccelerometerDataService . ref " ; 1 f stream in; in . open (ref File) ; CORBA Object var obj orb~&gt;stnng_to_object (s) ;

AccelerometerDataServiceads AccelerometerDataService: :_narrow(ob]) ; ads - &gt;update ( x , y , z ) ;

[0059] FIGURE 5A illustrates aspects of an interactive proximity display tether with co-play within one embodiment of the CO-PLAY. As shown in Figure 5A, a source device 550 (e.g., a smart mobile device, etc.) may establish a communication path with target device 551 (e.g., a television, a desktop, a laptop, etc.) across communications network 555, such as, but not limited to Bluetooth, 3G network, WiFi, Ethernet, and/or the like. In some implementations, target device 551 may be connected via cable 557 to display device 553 and configured to push the target display data to the display device. Otherwise, target device 551 may display CO-PLAY data on the target's display or in 1 combination with the display device 553 as a dual monitor implementation.

2 [0060] In one embodiment, the source device 550 may tether with the target

3 device 551 as discussed in Figures 3A-3C. In one implementation, depending on the

4 processing capabilities of target 551, the source device 550 may drive

5 communications/processing implementing server functionality, while pushing data for

6 display to the target device 551 which would facilitate client functionality for CO-PLAY.

7 In an alternative implementation, the source device 550 may be able to offload data

8 processing functionality to the target device 551, which could facilitate server

9 functionality. In that case, the source device 550 would facilitate client functionality,

10 whereas the target device 551 would facilitate server functionality for CO-PLAY. For

11 example, in one implementation, a user may engage a gaming application on an Apple

12 iPhone as the source device and project the gaming visualization to the screen of a

13 desktop as the target device. For another example, the gaming application may be

14 engaged on the target device (e.g., a laptop) , and the user may operate the source device

15 (e.g., a gameboy) as a remote control to interactively control the game.

16 [0061] In one embodiment, a second mobile device (e.g., a second smart mobile

17 device, etc.) may be incorporated into the CO-PLAY. In one implementation, the source

18 device 550 may establish a communication path via a communications network 556 (e.g.,

19 Bluetooth, 3G network, WiFi, Ethernet, etc.) to include a client device 552. Once the

20 communications path is established, client device may be configured to sense user

21 manipulation of the device and transmit the data across the communications network

22 556 to the source device 550. If the source device 550 is facilitating server functionality,

23 the source device 550 may process the data from client device 552 and forward to the 1 target device 551 for display. On the other hand, if source device 550 is facilitating client

2 functionality with the target device 551 facilitating server functionality, the source device

3 550 may act as a conduit to relay the user manipulation data from the client device 552

4 to the target device 551.

5 [0062] In one embodiment, the CO-PLAY may be configured to facilitate the

6 client device 552 and the source device 550 interacting in an interactive gaming

7 platform that is displayed by target device 551 or display device 553. For example, in

8 one implementation, the user interactions with respective devices 550 and 552 may be

9 displayed in realtime in an iGolf, iTennis or similar interactive co-play games,0 represented by first and second avatars 558 and 559, respectively. 1 [0063] Figure 5B illustrates aspects of an interactive proximity display tether with2 co-play within an alternative embodiment of the CO-PLAY. In one embodiment, instead3 of the client device 562 establishing a communication path and communicating with the4 CO-PLAY through the source device 560, the client device 562 establishes a5 communication path and communicates with the CO-PLAY directly through target6 device 561 across communications network 566 after source/target device client/server7 functionality has been established. In one implementation, the CO-PLAY in Figure 5B8 will facilitate the client device 562 and source device interacting in the gaming platform9 that is displayed by the target device 561 or display device 563. 0 [ 0064] FIGURE 5C illustrates aspects of an interactive proximity display tether1 with co-play within another alternative embodiment of the CO-PLAY. In one2 embodiment, client device 572-A may join the Co-play IPDT by first connecting with3 client device 572-B across communications network 576 which in turn may join with 1 target device 371 to achieve CO-PLAY. In one embodiment, target device 571 facilitates

2 server functionality and as such, drives the processing of user inputs from source device

3 570, and client devices 572-A/572-B. Once the client device data is processed by target

4 device 571, target device 571 may display persistent platform gameplay on its display

5 and/or via a tethered display 574A. In some instances, target device 571 may also

6 transmit display data back to client device 572B for display on the client device 572B or

7 tethered display 573B.

8 [ 0065] FIGURE 5D illustrates aspects of an interactive proximity display tether

9 with co-play within another alternative embodiment of the CO-PLAY. In one

10 embodiment, target device 581 facilitates client functionality instead of server

11 functionality, which is facilitated by source device 580 in this implementation. As such,

12 to source device 580 receives and processes user interaction data from source device

13 580, as well as client device 582A via communication networks 584, 585, and 586

14 communicated through client devices 582B and 581. Once received, source device 580

15 processes and serves the processed user interaction data back to target 581 and client

16 582B for display.

17 [ 0066] The CO-PLAY facilitate significant flexibility and may be configured in a

18 wide variety of implementations. Although a few example implementations are

19 discussed herein to facilitate understanding the features achieved by CO-PLAY, it is to

20 be understood that this disclosure contemplates variations of the various example

21 implementations explicitly described herein. Further, although the examples described

22 herein discuss implementations with two mobile devices and one or two laptops, it is to

23 be understood that CO-PLAY implementations may be configured to facilitate communication between more than two client devices. It should be further noted that disparate devices may engage in co-playing, e.g., a gameboy co-play session with an iPhone, a PSP co-play session with a Google Android, etc.

[0067] FIGURE 6A provides an overall logic flow illustrating aspects of incorporating a co-play client device in one embodiment of the CO-PLAY. In one embodiment, a source device 602 may tether with a target device 603 as discussed in Figures 3A-C. In one embodiment, the source device may receive a request to include a client device for co-play 610. For example, a user may engage in a gaming platform that requires at least two players and then select a "co-play" mode from the gaming menu. For example, in one implementation, two palyers may each engage the Apple iPhone game "Fleet Air Superiority Training" (F.A.S.T.) application on their iPhone to co-play the game

[0068] In one embodiment, the source device may query for a co-play client device 612. In one implementation, the sensing and detecting for client device may be implemented in a similar manner as the query for a target device during a tethering process as discussed in Figure 3B. For example, in one implementation, the CO-PLAY source device 602 may search for a co-play device based on user submitted information such as, but not limited to known IP address, MAC address, acronym, hardware label, digital signature, driver certificate, zero-configuration information, and/or the like of a potential co-play client device. For another example, in an alternative implementation, the CO-PLAY source device may query the communication stack in the hardware database for registered devices/communication channels that are compatible with the source device. For another example, in an alternative implementation, the CO-PLAY source device may start a search to locate suitable co-play devices within a range of local area network by zero configuration protocols such as, but not limited to Service Location Protocol (SLP), Universal Plug and Play (UPnP), Jini, Bluetooth Service Discovery Protocol, WS-Discovery, Proprietary Discovery Protocol, Bonjour and/or the like. In such an implementation, a co-play client device may broadcast its availability and publish a server via a zero-configuration network, e.g. an Apple SDK may be used to create a Bonjour service.

[ 0069] In one embodiment, the CO-PLAY may generate a list of available co-play client devices 614, and present the list to a user via a user interface. In one embodiment, the CO-PLAY may receive a selection of co-play client device 615, and then send a request to the selected client device. The client device 602 may sense the co-play request (e.g., by receiving a co-play re quest message via zero-configuration conduit) and initialize a CO-PLAY enabled application 616. For example, in one implementation, the client device 601 may provide a pop-up window on screen displaying the received request to co-play. Upon receiving an affirmative indication, the client device may then initialize the co-play component.

[0070] In one embodiment, the CO-PLAY may establish a communications channel between the client device and the source device 617, as discussed in Figure 5A. The client device may then send control indications 618 to the source device. In one implementation, the source device and the client device may be connected via a wired cable such as a dock connector cable that is directly plugged in the mobile device, or wireless network, such as Bluetooth, 3G, Wi-Fi and/or the like.

[0071] In one implementation, the CO-PLAY may receive and integrate control indications from both the client device and the source device to engage the gaming application. For example, in one implementation, a user may engage the client and or the source device as a remote control, such as a gameboy, etc., and input control commands via a user interface (e.g., mouse, keyboard, etc.). For another example, a user may engage a CO-PLAY remote control device housing in an emulating equipment, such as a golf club, a tennis racquet and/or the like. The user may swing the remote control device as if swinging a real golf club or tennis racquet in field, and the sensor of the client or the source device may detect signals of the motion of the club or racquet and transfer the signals (e.g. electrical pulses from accelerometers indicating a velocity and a direction of a swing, etc.). The client or source device may process and analyze the received signals and generate data describing characteristics of the movement, e.g. direction of the movement, speed of the movement, motion level, etc., and transmit the data to the CO-PLAY. For example, in one embodiment, the iPhone SDK toolkit and/or runtime libraries may be installed and/or used to access, obtain such inputs, and interpret such actions. [0072] In one implementation, the communications between the client device and the source device may be supported by a method-call semantics mechnism, e.g., CORBA, as discussed in Figure 4. For exmaple, in one implementation, the gaming application runnning on the source device may interface an object request borker of a CORBA infrastructure to invoke a remote object on the gaming application running on the client device, e.g., each co-player is defined as an object. In one implementation, an example C/C++ implementation of defining a player object (a source device or a client device) in the F.A.S.T. gaming platform, may take a form similar to: struct Player

Peer *peer; //client listening server port

bool ready; // ready state intβ plane; // plane index char name [32 J ; // client name

Plane ''airplane ;

bool isDisconnected ; // Player disconnected

iπt kills; int deaths ; int8 team;

int ranking; int rankPosition; int ranklfwin; int ranklfLose ;

int ranksPerTeam 14] ;

[0073] In one embodiment, the CO-PLAY source device may send display indications to the target device 622, and display an enlarged gaming visualization on the screen of the target device 623 in a real-time manner via the established tethering between the source device and the target device. [0074] FIGURE 6B provides an overall logic flow illustrating aspects of incorporating a co-play client device in an alternative embodiment of the CO-PLAY. For example, in one implementation, upon receiving a selection of co-play client device, instead of establishing communications between the source device and the client device, the CO-PLAY client device may directly establish a communications channel with the target device 630. In one implementation, in addition to the implementations described in Figure 6A for querying for co-play client device 612, the target device may engage as a gaming server to drive the co-play platform and provide a list of available players. For example, in one implementation, both the source device and the client device may access an Internet gaming platform and register with their IP address, MAC address, user account etc., whereby the target device may be a computer connected to the Internet gaming server. In such an implementation, a user may use the web browser running on the source device to navigate to the gaming server on the target device. As such, a user may view a list of co-players published from the target device (the Internet gaming server) available via Wi-Fi.

[0075] In one embodiment, a player operating the source device may submit a selection of co-play client device to the target device, and CO-PLAY may establish communications between the target device and the client device 630. In one implementation, the target device may tether with the client device in similar manners as discussed in Figure 3C. For example, in one implementation, the CO-PLAY client device may tether with the target device via a physical tether, e.g., a direct audio/video connection such as an iPhone Video AV to Dock Connector Cable that is plugged directly into a large television, a Casio XJ-S57 with a WiFi YW-2 adapter connected via WiFi, and/or the like. For another example, in an alternative implementation, the CO-PIAY client device may connect with a secured application server running on or connected to the target device, e.g., a distributed object oriented application, a web server, a remote display client (e.g., citrix, VNC, etc.), a web browser, and/or the like. For another example, in an alternative implementation, the target device may be broadcasting based on a zero-configuration protocol (e.g. Bonjour, SLP, UPnP, Jini, Bluetooth Service Discovery Protocol, WS-Discovery, Proprietary Discovery Protocol, and/or the like) or responding to a proprietary communication request to tether with the client device. [OO76] In one embodiment, the client device may directly submit control indications to the target device 632. If the target device acts as the gaming server to drive the co-play platform, the target device may receive control indications from the source device and the client device to engage the co-play gaming application 634. For example, the target device (e.g., a computer, etc.) may obtain and run a gaming application component from the Internet. In an alternative implementation, if the source device acts as the gaming server, the target device may forward the control indications to the source device to engage the co-play gaming application 634.

[ 0077] In one implementation, the source device may send display indications to target device 636 for remote display visualization 638. In an alternative implementation, as shown in Figures 5C and 5D, the client device and the source device may tether with different target devices, respectively, and each of the target devices may be connected to a large display (e.g., a television, a projector, etc.) for visualization. In one implementation, the target devices may be connected via a communications network to exchange gaming data in real time. For example, each of two users may employ a mobile device to tether with a separate computer, respectively, and both of the computers may access an Internet gaming server to engage the users for co-play.

[0078] In one implementation, a iPhone SDK application of defining an object of querying and testing reachability of a client device over the network may take a form similar to: 1 (Bclass Reachability;

2 ©interface Reachability : NSObject {

3 ©private

4 BOOL _networkStatusNotif icationsEnabled;

5 NSStπng *_hostName;

6 NSString *_address;

7 NSMutableDictionary *_reachabilityQueries ;

9

10 /*

11 When reachability change notifications are posted, the callback method

12 ' ReachabilityCallback¹ is called

13 and posts a notification that the client application can observe to learn

14 about changes.

15 */

16 static void Reachabi lityCallback (SCNetworkReachabil ityRef target, "¹J SCNetworkReachabi 1 i tyFlaσs flags, void *inio) ;

18 -end

19

20 ©implementation Reachability

21

22 ©synthesize networkStatusNotificationsEnabled =

23 _networkStatusNotificationsEnabled ;

24 Θsynthesize hostName = _hostName;

25 ©synthesize address = _address,-

26 ©synthesize reachabi] ityQueries = _reachabilityQueπes ; 27

28 + (Reachability * ) sharedReachability

29 {

30 // This returns YES if the address 169.254.0.0 is reachable without

31 requiring a connection.

32 - (BOOL) isAdHocWiFiNetworkAvai lableFlags : (SCNetworkReachabil ityFlags *)outFlags

33 {

34 // Look in the cache of reachability queries for one that matches this

35 query.

36 ReachabilityQuery *query - [self . reachabilityQueπes

37 ob^ectForKey : kLinkLocalAddressKey] ;

38 SCNetworkReachabilityRef adHocWiFiNetworkReachability =

39 query . reachabilityRef ;

40

41 } 1 ©end

2 [0079] FIGURE 7 A shows an overall logic flow illustrating CO-PLAY in an

3 alternative embodiment of CO-PLAY operation. The logic flow shown is directed to an

4 alternative embodiment of the CO-PLAY employing remote access software, such as

5 Citrix or VNC, to couple a mobile source device with a target device as a remote display,

6 as well as available client devices. A user may engage a mobile source device application

7 701, such as by turning on the mobile device, selecting an application icon, and/or the

8 like. In one implementation, both an application and remote access software may be

9 engaged at the mobile source device. A remote display target device application may

10 also be engaged 704, such as by turning on the mobile device, selecting an application

11 (e.g., remote access software), and/or the like. The mobile source device and/or the

12 remote display target device may check for a data link to the counterpart device, such as

13 by pinging the counterpart 707 and a determination may be made as to whether a data

14 link has been established 710. If not, then the mobile source device and/or the remote

15 display target device may retry establishing a data link, such as by repairing and/or

16 refreshing a network connection, presenting an error message via a user interface and

17 requesting that the user check communication components, and/or the like 713.

18 [0080] Once the source device and target establish a viable communications path,

19 the CO-PLAY may check whether additional client devices are available to be

20 incorporated into the CO-PLAY 716. If so, the communication paths are established

21 707-710. Otherwise, sensor components may receive sensor inputs 719 that may cause

22 user interaction updates to a mobile source device application configuration 722. For

23 example, in one implementation, a sensor input may comprise a state of motion, such as

24 may be detected by an accelerometer. This state of motion mav be translated into a 1 virtual state of motion for an avatar or other virtual entity in the context of a mobile

2 device application, such as a video game. A determination may be made at 725 as to

3 whether or not a send period has concluded. If not, then the user's source/client device

4 may wait for a period of time 728 and check whether any new inputs have been received

5 from the sensors 731. If so, then the user device may add the most recent set of sensor e inputs and/or corresponding application configurations to a display signal cache 734

7 and proceed to receive the new sensor inputs 719. Otherwise, the user's source/client

8 device may return to 725 to check whether the send period has concluded. Once a send

9 period has concluded, the user's source/client device may configure a display signal0 message corresponding to a current and/or set of recent application states 738. For1 example, in one implementation, the display signal may represent a current and/or set2 of recent positions and/or states of motions of an avatar in a video game. 3 [0081] In implementation's where the source device facilitates server4 functionality, the user's source/client device may update remote access software at the5 source device, such as Citrix, VNC, and/or the like 741, and send the corresponding6 display signal to the remote display target device 744. The remote display on target? device 744, in turn, may provide a visualization of the display signal, such as on a8 display screen 747. A determination may be made as to whether to continue with Co-9 play IPDT operation 750. If so, then the user's source/client device transition to receive0 further sensor inputs 719. Otherwise, the IPDT CO-PLAY is completed 753. 1 [0082] FIGURE 7B shows an overall logic flow illustrating CO-PLAY in an2 alternative embodiment of CO-PLAY operation. The logic flow shown in Fig. 6B is3 directed to an alternative embodiment of the user's source/client device employing web 1 server software to couple a mobile source device to a remote display target device, such

2 as by publishing mobile device application data to a web site for retrieval by an internet-

3 connected target device. A user may engage a user's source/client device application

4 756, such as by turning on the mobile source/client device, selecting an application icon,

5 and/or the like. In one implementation, both an application and web server software

6 may be engaged at the mobile device. The user's source/client device's sensor

7 components may receive sensor inputs 759 that may cause updates to a mobile device

8 application configuration 762. A determination may be made at 765 as to whether or

9 not a web client data request, such as an HTTP request, has been received. If not, then0 the user's source/client device may wait for a period of time 768 and check whether any1 new inputs have been received from the sensors 772. If so, then the user's source/client2 device may add the most recent set of sensor inputs and/or corresponding application3 configurations to a display signal cache 775 and proceed to receive the new sensor4 inputs 759. Otherwise, the user's source/client device may return to 765 to check5 whether a web client data request has been received. In an alternative implementation,6 the user's source/client device may send display signals to a target device without regard7 to whether a web client data request has been received or not. In this implementation,8 the user's source/client device may send display signals to an intermediary repository.9 The repository, then, may monitor the receipt of web client data requests and provide0 one or more current or historical display signals to the web client supplying the data1 request. 2 [0083] Once a web client data request has been received, the user's source/client3 device may configure a display signal message corresponding to a current and/or set of4 recent application states 778. The configured display signal may be published on the 1 World Wide Web via web server software 781. The published application state content

2 may then be accessed by one or more remote display target devices, such as by accessing

3 a web site on which the application state data is hosted 784. In one implementation,

4 application state data may be represented on a website as an integrated video,

5 animation, rich Internet application, and/or the like configured in accordance with a 8 multimedia plug-in such as Adobe Flash. A determination may be made at 787 as to ? whether to update the displayed visualization of the application state at the remote

8 display. If so, then additional sensor inputs are received at 759. Otherwise, the CO-

9 PLAY session concludes 790. 0 [ 0084] FIGURE 8A-8C provide examples of screenshots from an Apple iPhone1 F.A.S.T. gameplay platform illustrating aspects of a CO-PLAY gaming application within2 a CO-PLAY operation. In Figure 8A, a user may be provided options to launch a CO-3 PLAY gaming application 870, and upon choosing the "competition," the user may be4 presented a list of gaming connection options 872. In one embodiment, if the user5 chooses "Bluetooth," the CO-PLAY may search for another iPhone or other tether target6 devices via Bluetooth network 873, and present a list of available co-play client devices7 (and/or tether target) to the user 875. The user may then select a client device 878 for8 co-play and connect with the tether target 880. Upon establishing connection with the9 client device (in this case another iPhone), the CO-PLAY application may be engaged on0 both the source device and the client device 882 and 883 to facilitate co-play. 1 [0085] In one embodiment, as illustrated in Figure 8B, if the user chooses "lobby2 list" in the "competition" menu 872, the CO-PLAY may provide a list of available3 "lobbies" on a gaming host server 874. Upon user's selection of a lobby, the IPDT may connect to a host server 876/878 and load the video game on the user device 882/883. In another embodiment, as illustrated in Figure 8C, if the user selects "market" at 870, the CO-PLAY application may provide gaming features for sale 386. In another embodiment, if the user selects "social" at 870, the CO-PLAY application may provide an option to publish the gaming feeds of the user via social media (e.g. through Facebook, etc.) 888.

[0086] Figures 8D-8F provide examples of screen shots from an Apple iPhone iTennis gameplay platform illustrating aspects of a CO-PLAY gaming application within a CO-PLAY operation. For example, in one implementation, a user may launch an iTennis application on an iPhone, and view a list of available games. In one implementation, the user may search for available games 850 by entering the name of the game, and/or a co-player's name. In Figure 8E, a list of available players in the "booth" 860 is shown to the user upon user selection of a game. In one implementation, the list may also indicate whether an active player is iPhone connected or not 855/862. In one implementation, a user may configure the game to be public or private 865, i.e., whether the engaged game may be viewed by other active players outside the game. In one implementation, the CO-PLAY may provide a list of friends of the user 864, and allow a user to search for a friend 863 based on friend information, such as player name, etc. Figure 8F shows an example screen shot of avatars of two players co-playing an iTennis game in one embodiment of a CO-PLAY operation.

[0087] FIGURE 9A is of a block diagram illustrating a CO-PLAY payment model. In one embodiment, a central service 905 may provide offering applications 915 via a subscription 910 or on any individual purchase basis. For example, offerings that otherwise may need to be purchased for a set price (e.g., $1.99 for each application) via a service such as the Apple App Store or may otherwise be accessed via a subscription service. In one embodiment, a service application may be downloaded onto the source device. Service applications once purchased may act to download games/offerings 920 free of charged for specified periods of time based on key sets. For example, the purchase date of the service application 905 may be used as a basis of providing offerings 915. For example, if the service application (e.g., iPlay) is purchased via the App Store on January 1, 2009, where the version of iPlay purchased is a 1 year subscription (e.g., for $19.99), then any offerings obtained up until January 1, 2010 will work accessing an authorization key within the iPlay application, that key expiring at the end of the year.

[0088] FIGURE 9B is of a block diagram illustrating a CO-PLAY screens. In one embodiment, the subscription model may be wrapped in its own application 925 and execute as a full application on the source device 929 including icons and splash screens. Offerings, e.g., iTennis, 930 in a subscription model will work as full applications with instructions 940 and game screens. Locked versions of the offerings may have a zippered appearance 935 when out of subscription, which may be unlocked under a renewed subscription.

Interactive Extensions [0089] Another advantage to the CO-PLAY involves features that may extend interaction with applications. Such extensions are particularly useful in the areas of electronic gaming. For example, when a source device, e.g., an iPhone, is tethered to a target device, e.g., a large screen computer, the source device may then become a game controller input device relaying game data/instructions to the target device as it casts its display information across the communications tether. For example, a user may use an iPhone as an analogue to a tennis racquet, playing a virtual game of tennis via an iTennis application offering that is facilitated with a CO-PLAY component. Beyond using the iPhone as a tennis racquet handle for swinging the racquet, where the iPhones 3D accelerometers may be measured to obtain the dynamics of the string, the CO-PLAY can further extend features by employing the touch screen. For example, in one embodiment, a user can pinch the virtual tennis strings on the racquet together as they swing the iPhone to get an extra power boost in the game. Further, a user may use multitouch gestures to tighten or loosen the strings on the racquet, which will be used as additional input for the CO-PIAY application and will affect the dynamics of the game (e.g., loosened strings increasing power but decreasing accuracy).

[0090] Additionally, the CO-PLAY may be used to house user (e.g., game) profiles and progress. In this manner, user avatars and accounts such as (e.g., iMe) may be accessed on the source device even if the target device is unable and/or has no capacity to connect to the internet or otherwise gain access to the users profiles. In one embodiment, the profiles are mirrored and/or cached onto the source device, e.g., the iPhone, from a service on the internet. These settings may be transferred to the target device and/or accessed across the tether. Furthermore, such avatars and settings may be used to interact with other CO-PLAY application offerings. For example, two or more source devices, e.g., iPhones, from two different users may be simultaneously tethered onto a single target device and allowed to share a singular application space on the target application. For example, one of the two source devices can act as a host application and accept communication with the other source device. Thus, in one embodiment, where each user has a virtual avatar, the two avatars may be controlled in a common space on the target display simultaneously. Further, such an impromptu target virtual space may be the source for transactions between the parties: e.g., the avatars may trade valuable digital assets such as digital cash for digital objects (e.g., gold coins for enhanced game weapons and/or devices). In one embodiment, a common multiplaycr display housing all the source, e.g., iPhone, players may be seen on the single target device, but the displays of the source devices may have another view that is private to each users. In such an embodiment, users may interact in a common area on the target display and engage in secondary and/or private/secret strategic activities on their own personal displays.

[0091] In another embodiment, a single target display, like a large computer display or television would allow two or more players play high action games like ping- pong or tennis. In another embodiment, the CO-PLAY allows the source device to turn most any target device into an impromptu presentation display device.

[0092] FIGURE 9C shows aspects of different applications of a CO-PLAY in one embodiment. These may include, but are not limited to, games such as golf, bowling, billiards, baseball, shuffleboard, fishing, and/or the like.

[0093] FIGURES 10 show implementations of a CO-PLAY housing configured as a golf club in one embodiment. A mobile device such as an Apple iPhone may be secured in a housing shaped as a gaming implement, such as a golf club for a golf game, tennis racket for tennis game, fishing pole for a fishing game, baseball bat for a baseball game, and/or the like. As shown in Figure 10, in one implementation, 1001 provides a profile view of the gold club, which includes a grip coating with rubber, plastic 1005 and/or the like. The golf club also has a retracting extendible body with a slider 1006, as shown in the face view 1002. The golf club grip may also provide an iPhone cover to place an iPhone 1007, wherein the grip may have an example size of 7.5 inches by 2.75 inches. At the bottom of the golf club, a wrist strap holder 1008 may be provided, as shown in the face view 1002 and the bottom view 1003.

CO-PLAY Controller [0094] FIGURE 11 illustrates inventive aspects of an CO-PLAY controller 1101 in a block diagram. In this embodiment, the CO-PIAY controller 1101 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through real time control and resource sharing technologies, and/or other related data.

[0095] Typically, users, which may be people and/or other systems, may engage information technology systems (e.g., computers) to facilitate information processing. In turn, computers employ processors to process information; such processors 1103 may be referred to as central processing units (CPU). One form of processor is referred to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory 1129 (e.g., registers, cache memory, random access memory, etc.). Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations. These stored instruction codes, e.g., programs, may engage the CPU circuit components and other 1 motherboard and/or system components to perform desired operations. One type of

2 program is a computer operating system, which, may be executed by CPU on a computer;

3 the operating system enables and facilitates users to access and operate computer

4 information technology and resources. Some resources that may be employed in

5 information technology systems include: input and output mechanisms through which

6 data may pass into and out of a computer; memory storage into which data may be ? saved; and processors by which information may be processed. These information a technology systems may be used to collect data for later retrieval, analysis, and 9 manipulation, which may be facilitated through a database program. These information0 technology systems provide interfaces that allow users to access and operate various1 system components. 2 [ 0096] In one embodiment, the CO-PLAY controller 1101 may be connected to3 and/or communicate with entities such as, but not limited to: one or more users from4 user input devices 1111; peripheral devices 1112; an optional cryptographic processor5 device 1128; and/or a communications network 1113. 6 [0097] Networks are commonly thought to comprise the interconnection and7 interoperation of clients, servers, and intermediary nodes in a graph topology. It should8 be noted that the term "server" as used throughout this application refers generally to a9 computer, other device, program, or combination thereof that processes and responds to0 the requests of remote users across a communications network. Servers serve their1 information to requesting "clients." The term "client" as used herein refers generally to a2 computer, program, other device, user and/ or combination thereof that is capable of3 processing and making requests and obtaining and processing any responses from servers across a communications network. A computer, other device, program, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a "node." Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked with furthering the passage of information from a source to a destination is commonly called a "router." There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is generally accepted as being an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate with one another.

[ 0098] The CO-PlAY controller 1101 may be based on computer systems that may comprise, but are not limited to, components such as: a computer systemization 1102 connected to memory 1129.

Computer Systemization [ 0099] A computer systemization 1102 may comprise a clock 1130, central processing unit ("CPU(s)" and/or "processor(s)" (these terms are used interchangeable throughout the disclosure unless noted to the contrary)) 1103, a memory 1129 (e.g., a read only memory (ROM) 1106, a random access memory (RAM) 1105, etc.), and/or an interface bus 1107, and most frequently, although not necessarily, are all interconnected and/or communicating through a system bus 1104 on one or more (mother)board(s) 1102 having conductive and/or otherwise transportive circuit pathways through which instructions (e.g., binary encoded signals) may travel to effect communications, operations, storage, etc. Optionally, the computer systemization may be connected to an internal power source 1186. Optionally, a cryptographic processor 1126 may be connected to the system bus. The system clock typically has a crystal oscillator and generates a base signal through the computer systemization's circuit pathways. The clock is typically coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of instructions embodying information throughout a computer systemization may be commonly referred to as communications. These communicative instructions may further be transmitted, received, and the cause of return and/or reply communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems.

[00100] The CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. Often, the processors themselves will incorporate various specialized processing units, such as, but not limited to: integrated system (bus) controllers, memory management control units, floating point units, and even specialized processing sub-units like graphics processing units, digital signal processing units, and/or the like. Additionally, processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 529 beyond the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level i, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a memory address space that is accessible via instruction address, which the processor can construct and decode allowing it to access a circuit path to a specific memory address space having a memory state. The CPU may be a microprocessor such as: AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory' through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic and/or optic circuits) to execute stored instructions (i.e., program code) according to conventional data processing techniques. Such instruction passing facilitates communication within the CO-PLAY controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed CO-PLAY), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed.Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed.

[00101] Depending on the particular implementation, features of the CO-PLAY may be achieved by implementing a microcontroller such as CAST's R8051XC2 microcontroller; Intel's MCS 51 (i.e., 8051 microcontroller); and/or the like. Also, to implement certain features of the CO-PLAY, some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit ("ASIC"), Digital Signal Processing ("DSP"), Field Programmable Gate Array ("FPGA"), and/or the like embedded technology. For example, any of the CO-PLAY component collection (distributed or otherwise) and/or features may be implemented via the microprocessor and/or via embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of the CO-PLAY ma y be implemented with embedded components that are configured and used to achieve a variety of features or signal processing.

[00102] Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/software solutions. For example, CO-PLAY features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the CO- PIAY features. A hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the CO-PLAY system designer/administrator, somewhat like a one-chip programmable breadboard. An FPGA's logic blocks can be programmed to perform the function of basic logic gates such as AND, and XOR, or more complex combinational functions such as decoders or simple mathematical functions. In most FPGAs, the logic blocks also include memory elements, which may be simple flip-flops or more complete blocks of memory. In some circumstances, the CO-PLAY may be developed on regular FPGAs and then migrated into a fixed version that more resembles ASIC implementations. Alternate or coordinating implementations may migrate CO- PLAY controller features to a final ASIC instead of or in addition to FPGAs. Depending 1 on the implementation all of the aforementioned embedded components and

2 microprocessors may be considered the "CPU" and/or "processor" for the CO-PLAY.

3 Power Source

4 [00103] The power source 1186 may be of any standard form for powering small

5 electronic circuit board devices such as the following power cells: alkaline, lithium

6 hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. ? Other types of AC or DC power sources may be used as well. In the case of solar cells, in

8 one embodiment, the case provides an aperture through which the solar cell may

9 capture photonic energy. The power cell 1186 is connected to at least one of the0 interconnected subsequent components of the CO-PLAY thereby providing an electric1 current to all subsequent components. In one example, the power source 1186 is2 connected to the system bus component 1104. In an alternative embodiment, an outside3 power source 1186 is provided through a connection across the I/O 1108 interface. For4 example, a USB and/or IEEE 1394 connection carries both data and power across the5 connection and is therefore a suitable source of power. 6 Interface Adapters 7 [00104] Interface bus(ses) 1107 may accept, connect, and/or communicate to a8 number of interface adapters, conventionally although not necessarily in the form of9 adapter cards, such as but not limited to: input output interfaces (I/O) 1108, storage0 interfaces 1109, network interfaces 1110, and/or the like. Optionally, cryptographic1 processor interfaces 1127 similarly may be connected to the interface bus. The interface2 bus provides for the communications of interface adapters with one another as well as3 with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters conventionally connect to the interface bus via a slot architecture. Conventional slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISΛ), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.

[00105] Storage interfaces 1109 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 1114, removable disc devices, and/or the like. Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.

[00106] Network interfaces 1110 may accept, communicate, and/or connect to a communications network 1113. Through a communications network 1113, the CO-PLAY controller is accessible through remote clients 1133b (e.g., computers with web browsers) by users 1133a. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 8θ2.πa-x, and/or the like. Should processing requirements dictate a greater amount speed and/or capacity, distributed network controllers (e.g., Distributed CO-PLAY), architectures may similarly be employed to pool, load balance, and/or otherwise increase the communicative bandwidth required by the CO-PLAY controller. A communications network may be any 1 one and/or the combination of the following: a direct interconnection; the Internet; a

2 Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating

3 Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area

4 Network (WAN); a wireless network (e.g., employing protocols such as, but not limited

5 to a Wireless Application Protocol (WAP), 1-mode, and/or the like); and/or the like. A

6 network interface may be regarded as a specialized form of an input output interface. ? Further, multiple network interfaces mo may be used to engage with various

8 communications network types 1113. For example, multiple network interfaces may be

9 employed to allow for the communication over broadcast, multicast, and/or unicast0 networks. 1 [00107] Input Output interfaces (I/O) 1108 may accept, communicate, and/or2 connect to user input devices 1111, peripheral devices 1112, cryptographic processor3 devices 1128, and/or the like. I/O may employ connection protocols such as, but not4 limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple5 Desktop Bus (ADB), IEEE i394a-b, serial, universal serial bus (USB); infrared; joystick;6 keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface: Apple Desktop7 Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface8 (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA,9 and/or the like; wireless: 802.na/b/g/n/x, Bluetooth, code division multiple access0 (CDMA), global system for mobile communications (GSM), WiMax, etc.; and/or the like.1 One typical output device may include a video display, which typically comprises a2 Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an3 interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may4 be used. The video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Another output device is a television set, which accepts signals from a video interface. Typically, the video interface provides the composited video information through a video connection interface that accepts a video display interface (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVl connector accepting a DVI display cable, etc.).

[00108] User input devices 1111 may be card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, mouse (mice), remote controls, retina readers, trackballs, trackpads, and/or the like.

[00109] Peripheral devices 1112 may be connected and/or communicate to I/O and/or other facilities of the like such as network interfaces, storage interfaces, and/or the like. Peripheral devices may be audio devices, cameras, dongles (e.g., for copy protection, ensuring secure transactions with a digital signature, and/or the like), external processors (for added functionality), goggles, microphones, monitors, network interfaces, printers, scanners, storage devices, video devices, video sources, visors, and/or the like.

[00110] It should be noted that although user input devices and peripheral devices may be employed, the CO-PLAY controller may be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided over a network interface connection.

[00111] Cryptographic units such as, but not limited to, microcontrollers, processors 1126, interfaces 1127, and/or devices 1128 may be attached, and/or communicate with the CO-PLAY controller. A MC68HC16 microcontroller, 1 manufactured by Motorola Inc., may be used for and/or within cryptographic units. The

2 MC68HC16 microcontroller utilizes a 16-bit multiply-and-aecumulate instruction in the

3 16 MHz configuration and requires less than one second to perform a 512-bit RSA

4 private key operation. Cryptographic units support the authentication of

5 communications from interacting agents, as well as allowing for anonymous

6 transactions. Cryptographic units may also be configured as part of CPU. Equivalent ? microcontrollers and/or processors may also be used. Other commercially available

8 specialized cryptographic processors include: the Broadcom's CryptoNetX and other

9 Security Processors; nCipher's nShield, SafeNet's Luna PCI (e.g., 7100) series;0 Semaphore Communications' 40 MHz Roadrunner 184; Sun's Cryptographic1 Accelerators (e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); Via2 Nano Processor (e.g., L2100, L2200, U2400) line, which is capable of performing 500+3 MB/s of cryptographic instructions; VLSI Technology's 33 MHz 6868; and/or the like. 4 Memory 5 [00112] Generally, any mechanization and/or embodiment allowing a processor to6 affect the storage and/ or retrieval of information is regarded as memory 1129. However,7 memory is a fungible technology and resource, thus, any number of memory8 embodiments may be employed in lieu of or in concert with one another. It is to be9 understood that the CO-PLAY controller and/or a computer systemization may employ0 various forms of memory 1129. For example, a computer systemization may be1 configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM,2 ROM, and any other storage devices are provided by a paper punch tape or paper punch3 card mechanism; of course such an embodiment would result in an extremely slow rate 1 of operation. In a typical configuration, memory 1129 will include ROM 1106, RAM 1105,

2 and a storage device 1114. Λ storage device 1114 may be any conventional computer

3 system storage. Storage devices may include a drum; a (fixed and/or removable)

4 magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray, CD

5 ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); an

6 array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state

7 memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable β storage mediums; and/or other devices of the like. Thus, a computer systemization 9 generally requires and makes use of memory.

10 Component Collection

11 [00113] The memory 1129 may contain a collection of program and/or database

12 components and/or data such as, but not limited to: operating system component(s)

13 1115 (operating system); information server component(s) 1116 (information server);

14 user interface component(s) 1117 (user interface); Web browser component(s) 1118

15 (Web browser); database(s) 1119; mail server component(s) 1121; mail client

16 component(s) 1122; cryptographic server component(s) 1120 (cryptographic server); the

17 CO-PLAY component(s) 1135; and/or the like (i.e., collectively a component collection).

18 These components may be stored and accessed from the storage devices and/or from

19 storage devices accessible through an interface bus. Although non-conventional

20 program components such as those in the component collection, typically, are stored in

21 a local storage device 1114, they may also be loaded and/or stored in memory such as:

22 peripheral devices, RAM, remote storage facilities through a communications network,

23 ROM, various forms of memory, and/or the like. 1 Operating System

2 [00114] The operating system component 1115 is an executable program

3 component facilitating the operation of the CO-PLAY controller. Typically, the operating

4 system facilitates access of I/O, network interfaces, peripheral devices, storage devices,

5 and/or the like. The operating system may be a highly fault tolerant, scalable, and e secure system such as: Apple Macintosh OS X (Server); AT&amp;T Plan 9; Be OS; Unix and

7 Unix-like system distributions (such as AT&amp;T's UNIX; Berkley Software Distribution

8 (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux

9 distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating0 systems. However, more limited and/or less secure operating systems also may be1 employed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows2 2OOO/2OO3/3.i/95/98/CE/Millenium/NT/Vista/XP (Server), Palm OS, and/or the like.3 An operating system may communicate to and/or with other components in a4 component collection, including itself, and/or the like. Most frequently, the operating5 system communicates with other program components, user interfaces, and/or the like.6 For example, the operating system may contain, communicate, generate, obtain, and/or7 provide program component, system, user, and/or data communications, requests,8 and/or responses. The operating system, once executed by the CPU, may enable the9 interaction with communications networks, data, I/O, peripheral devices, program0 components, memory, user input devices, and/or the like. The operating system may1 provide communications protocols that allow the CO-PLAY controller to communicate2 with other entities through a communications network 1113. Various communication3 protocols may be used by the CO-PLAY controller as a subcarrier transport mechanism4 for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like.

Information Server [00115 J An information serv er component 1116 is a stored program component that is executed by a CPU. The information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the like. The information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other 1 program components. After a Domain Name System (DNS) resolution portion of an

2 HTTP request is resolved to a particular information server, the information server

3 resolves requests for information at specified locations on the CO-PLAY controller based

4 on the remainder of the HTTP request. For example, a request such as

5 http://123.124.125.126/mylnformation.html might have the IP portion of the request e "123.124.125.126" resolved by a DNS server to an information server at that IP address;

7 that information server might in turn further parse the http request for the

8 "/my Information. html" portion of the request and resolve it to a location in memory

9 containing the information "mylnformation.html." Additionally, other information0 serving protocols may be employed across various ports, e.g., FTP communications1 across port 21, and/or the like. An information server may communicate to and/or with2 other components in a component collection, including itself, and/or facilities of the like.3 Most frequently, the information server communicates with the CO-PLAY database 1119,4 operating systems, other program components, user interfaces, Web browsers, and/or5 the like. 6 [00116] Access to the CO-PIAY database may be achieved through a number of7 database bridge mechanisms such as through scripting languages as enumerated below8 (e.g., CGI) and through inter-application communication channels as enumerated below9 (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed0 through the bridge mechanism into appropriate grammars as required by the CO-PLAY.1 In one embodiment, the information server would provide a Web form accessible by a2 Web browser. Entries made into supplied fields in the Web form are tagged as having3 been entered into the particular fields, and parsed as such. The entered terms are then4 passed along with the field tags, which act to instruct the parser to generate queries 1 directed to appropriate tables and/or fields. In one embodiment, the parser may

2 generate queries in standard SQL by instantiating a search string with the proper

3 join/select commands based on the tagged text entries, wherein the resulting command

4 is provided over the bridge mechanism to the CO-PLAY as a query. Upon generating

5 query results from the query, the results are passed over the bridge mechanism, and

6 may be parsed for formatting and generation of a new results Web page by the bridge

7 mechanism. Such a new results Web page is then provided to the information server,

8 which may supply it to the requesting Web browser.

9 [00117] Also, an information server may contain, communicate, generate, obtain,

10 and/or provide program component, system, user, and/or data communications,

11 requests, and/or responses.

12 User Interface

13 [00118] The function of computer interfaces in some respects is similar to

14 automobile operation interfaces. Automobile operation interface elements such as

15 steering wheels, gearshifts, and speedometers facilitate the access, operation, and

16 display of automobile resources, functionality, and status. Computer interaction

17 interface elements such as check boxes, cursors, menus, scrollers, and windows

18 (collectively and commonly referred to as widgets) similarly facilitate the access,

19 operation, and display of data and computer hardware and operating system resources,

20 functionality, and status. Operation interfaces are commonly called user interfaces.

21 Graphical user interfaces (GUIs) such as the Apple Macintosh Operating System's Aqua,

22 IBM's OS/2, Microsoft's Windows

23 2000/2003/3. i/95/98/CE/Millenium/NT/XP/Vista/7 (i.e., Aero), Unix's X-Windows (e.g., which may include additional Unix graphic interface libraries and layers such as K Desktop Environment (KDE), mythTV and GNU Network Object Model Environment (GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)I lTML, FLASH, Java, JavaScript, etc. interface libraries such as, but not limited to, Dojo, jQuery(UI), MooTools, Prototype, script. aculo. us, SWFObject, Yahoo! User Interface, any of which may be used and) provide a baseline and means of accessing and displaying information graphically to users.

[00119] A user interface component 1117 is a stored program component that is executed by a CPU. The user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as already discussed. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system. A user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like. The user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.

Web Browser [00120] A Web browser component 1118 is a stored program component that is executed by a CPU. The Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. Secure Web browsing may be supplied with i28bit (or greater) encryption b\ way of I fITPS, SSL, and/or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., Fire Fox, Safari Plug-in, and/or the like APIs), and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Of course, in place of a Web browser and information server, a combined application may be developed to perform similar functions of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the CO-PLAY enabled nodes. The combined application may be nugatory on systems employing standard Web browsers.

Mail Server [00121] A mail server component 1121 is a stored program component that is executed by a CPU 1103. The mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and/or the like. The mail server may allow for the execution of program components through facilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server may support 1 communications protocols such as, but not limited to: Internet message access protocol

2 (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange,

3 post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like. The

4 mail server can route, forward, and process incoming and outgoing mail messages that

5 have been sent, relayed and/or otherwise traversing through and/or to the CO-PLAY.

6 [ 00122] Access to the CO-PIAY mail may be achieved through a number of APIs

7 offered by the individual Web server components and/or the operating system.

β [00123] Also, a mail server may contain, communicate, generate, obtain, and/or 9 provide program component, system, user, and/or data communications, requests,0 information, and/or responses. 1 Mail Client 2 [ 00124] A mail client component 1122 is a stored program component that is3 executed by a CPU 1103. The mail client may be a conventional mail viewing application4 such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express,5 Mozilla, Thunderbird, and/or the like. Mail clients may support a number of transfer6 protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail7 client may communicate to and/or with other components in a component collection,8 including itself, and/or facilities of the like. Most frequently, the mail client9 communicates with mail servers, operating systems, other mail clients, and/or the like;0 e.g., it may contain, communicate, generate, obtain, and/or provide program1 component, system, user, and/or data communications, requests, information, and/or2 responses. Generally, the mail client provides a facility to compose and transmit3 electronic mail messages. 1 Cryptographic Server

2 [oo i25] A cryptographic server component 1120 is a stored program component

3 that is executed by a CPU 1103, cryptographic processor 1126, cryptographic processor

4 interface 1127, cryptographic processor device 1128, and/or the like. Cryptographic

5 processor interfaces will allow for expedition of encryption and/or decryption requests

6 by the cryptographic component; however, the cryptographic component, alternatively, ? may run on a conventional CPU. The cryptographic component allows for the

8 encryption and/or decryption of provided data. The cryptographic component allows for

9 both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or0 decryption. The cryptographic component may employ cryptographic techniques such1 as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital2 signatures, dual signatures, enveloping, password access protection, public key3 management, and/or the like. The cryptographic component will facilitate numerous4 (encryption and/or decryption) security protocols such as, but not limited to: checksum,5 Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data6 Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash7 function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internets encryption and authentication system that uses an algorithm developed in 1977 by Ron9 Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure0 Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like.1 Employing such encryption security protocols, the CO-PLAY may encrypt all incoming2 and/or outgoing communications and may serve as node within a virtual private3 network (VPN) with a wider communications network. The cryptographic component4 facilitates the process of "security authorization" whereby access to a resource is 1 inhibited by a security protocol wherein the cryptographic component effects authorized

2 access to the secured resource. In addition, the cryptographic component may provide

3 unique identifiers of content, e.g., employing and MD5 hash to obtain a unique

4 signature for an digital audio file. A cryptographic component may communicate to

5 and/or with other components in a component collection, including itself, and/or

6 facilities of the like. The cryptographic component supports encryption schemes

7 allowing for the secure transmission of information across a communications network β to enable the CO-PLAY component to engage in secure transactions if so desired. The 9 cryptographic component facilitates the secure accessing of resources on the CO-PLAY0 and facilitates the access of secured resources on remote systems; i.e., it may act as a1 client and/or server of secured resources. Most frequently, the cryptographic2 component communicates with information servers, operating systems, other program3 components, and/or the like. The cryptographic component may contain, communicate,4 generate, obtain, and/or provide program component, system, user, and/or data5 communications, requests, and/or responses. 6 The CO-PLAY Database 7 [00126] The CO-PLAY database component 1119 may be embodied in a database8 and its stored data. The database is a stored program component, which is executed by9 the CPU; the stored program component portion configuring the CPU to process the0 stored data. The database may be a conventional, fault tolerant, relational, scalable,1 secure database such as Oracle or Sybase. Relational databases are an extension of a flat2 file. Relational databases consist of a series of related tables. The tables are3 interconnected via a key field. Use of the key field allows the combination of the tables 1 by indexing against the key field; i.e., the key fields act as dimensional pivot points for

2 combining information from various tables. Relationships generally identify links

3 maintained between tables by matching primary keys. Primary keys represent fields that

4 uniquely identify the rows of a table in a relational database. More precisely, they

5 uniquely identify rows of a table on the "one" side of a one-to-many relationship.

6 [00127] Alternatively, the CO-PLAY database may be implemented using various ? standard data-structures, such as an array, hash, (linked) list, struct, structured text file β (e.g., XML), table, and/or the like. Such data-structures may be stored in memory 9 and/or in (structured) files. In another alternative, an object-oriented database may be0 used, such as Frontier, ObjectStore, Poet, Zope, and/or the like. Object databases can1 include a number of object collections that are grouped and/or linked together by2 common attributes; they may be related to other object collections by some common3 attributes. Object-oriented databases perform similarly to relational databases with the4 exception that objects are not just pieces of data but may have other types of5 functionality encapsulated within a given object. If the CO-PLAY database is6 implemented as a data-structure, the use of the CO-PLAY database 1119 may be7 integrated into another component such as the CO-PLAY component 1135. Also, the8 database may be implemented as a mix of data structures, objects, and relational9 structures. Databases may be consolidated and/or distributed in countless variations0 through standard data processing techniques. Portions of databases, e.g., tables, may be1 exported and/or imported and thus decentralized and/or integrated. 2 [ 00128] In one embodiment, the database component 1119 includes several tables3 liiga-e. In one embodiment, the database component 1119 includes several tables 1119a- e. A Users table 1119a may include fields such as, but not limited to: userJD, user name, user_^password, contadMnfo, hardware J D, payloadjiistory, user_evaluation and/or the like. A Hardware table 1119b may include fields such as, but not limited to: hardwareJD, hardware_type, hardware_name, data_formatting_jequirements, protocols, addressing_^Jnfo, usagejiistory, hardware_requirements, userJD, and/or the like. An Application table 1119c may include fileds such as, but not limited to: appJD, protocol__ID, userjype, app_type, app_^yersion, policyJD, app_setting, app_interface, app_authentication, and/or the like. A protocol table iH9d may include fields such as, but not limited to protocolJD, userJD, protocol_^version, protocoLjequest, protocol_compatability, and/or the like. A subscription table ni9e may include fields such as, but not limited to userJD, hardwareJD, subscriptionJD, subscription_^type, application _I D, application_^Jype, subscription_time, and/or the like.

[00129] In one embodiment, the CO-PLAY database may interact with other database systems. For example, employing a distributed database system, queries and data access by search CO-PLAY component may treat the combination of the CO-PLAY database, an integrated data security layer database as a single database entity.

[00130] In one embodiment, user programs may contain various user interface primitives, which may serve to update the CO-PLAY. Also, various accounts may require custom database tables depending upon the environments and the types of clients the CO-PLAY may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components liiga-e. The CO-PLAY may be configured to keep track of various settings, inputs, and parameters via database controllers.

[00131] The CO-PLAY database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the CO-PLAY database communicates with the CO-PIoAY component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data.

The CO-PLAYs [00132] The CO-PLAY component 1135 is a stored program component that is executed by a CPU. In one embodiment, the CO-PLAY component incorporates any and/or all combinations of the aspects of the CO-PLAY that was discussed in the previous figures. As such, the CO-PLAY affects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks.

[00133] The CO-PLAY component enables the configuration, network connection, engagement, remote control, and/or the like and use of the CO-PLAY.

[00134] The CO-PLAY component enabling access of information between nodes may be developed by employing standard development tools and languages such as, but 1 not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI)

2 (Objective-) C (++), C# and/or .NET, database adapters, CGI scripts, Java, JavaScript,

3 mapping tools, procedural and object oriented development tools, PERL, PHP, Python,

4 shell scripts, SQL commands, web application server extensions, web development

5 environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX &amp; FLASH;

6 AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype;

7 script. aculo. us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo! User β Interface; and/or the like), WebObjects, and/or the like. In one embodiment, the CO- 9 PLAY server employs a cryptographic server to encrypt and decrypt communications.0 The CO-PLAY component may communicate to and/or with other components in a1 component collection, including itself, and/or facilities of the like. Most frequently, the2 CO-PLAY component communicates with the CO-PLAY database, operating systems,3 other program components, and/or the like. The CO-PLAY may contain, communicate,4 generate, obtain, and/or provide program component, system, user, and/or data5 communications, requests, and/or responses. 6 Distributed CO-PLAYs 7 [00135] The structure and/or operation of any of the CO-PLAY node controller8 components may be combined, consolidated, and/or distributed in any number of ways9 to facilitate development and/or deployment. Similarly, the component collection may0 be combined in any number of ways to facilitate deployment and/or development. To1 accomplish this, one may integrate the components into a common code base or in a2 facility that can dynamically load the components on demand in an integrated fashion. 3 [00136] The component collection may be consolidated and/or distributed in 1 countless variations through standard data processing and/or development techniques.

2 Multiple instances of any one of the program components in the program component

3 collection may be instantiated on a single node, and/or across numerous nodes to

4 improve performance through load-balancing and/or data-processing techniques.

5 Furthermore, single instances may also be distributed across multiple controllers

6 and/or storage devices; e.g., databases. All program component instances and ? controllers working in concert may do so through standard data processing

8 communication techniques.

9 [00137] The configuration of the CO-PLAY controller will depend on the context of0 system deployment. Factors such as, but not limited to, the budget, capacity, location,1 and/or use of the underlying hardware resources may affect deployment requirements2 and configuration. Regardless of if the configuration results in more consolidated3 and/or integrated program components, results in a more distributed series of program4 components, and/or results in some combination between a consolidated and5 distributed configuration, data may be communicated, obtained, and/or provided.6 Instances of components consolidated into a common code base from the program7 component collection may communicate, obtain, and/or provide data. This may be8 accomplished through intra-application data processing communication techniques9 such as, but not limited to: data referencing (e.g., pointers), internal messaging, object0 instance variable communication, shared memory space, variable passing, and/or the1 like. 2 [00138] If component collection components are discrete, separate, and/or3 external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLt:), and/or the like), Common Object Request Broker Architecture (CORBA), local and remote application program interfaces Jini, Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter- application communication or within memory spaces of a singular component for intra- application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing functionality, which in turn may form the basis of communication messages within and between components. For example, a grammar may be arranged to recognize the tokens of an HTTP post command, e.g.: w3c -pos t ht trp : / / . . . Value l

[00139] where Valuel is discerned as being a parameter because "http://" is part of the grammar syntax, and what follows is considered part of the post value. Similarly, with such a grammar, a variable "Valuel" may be inserted into an "http://" post command and then sent. The grammar syntax itself may be presented as structured data that is interpreted and/or other wise used to generate the parsing mechanism (e.g., a syntax description text file as processed by lex, yacc, etc.). Also, once the parsing mechanism is generated and/or instantiated, it itself may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or readily available parsers (e.g., the SOAP parser) that may be employed to parse communications data. Further, the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment.

[00140] The entirety of this application (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, and otherwise) shows by way of illustration various embodiments in which the claimed inventions may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed inventions. It is further to be understood that, depending on the particular needs and/or characteristics of a CO-PLAY user, administrator, server, data, monetization structure, hardware configuration, network framework, and/or the like, various embodiments of the CO-PLAY may be implemented that facilitate a great deal of flexibility and customization. The instant disclosure discusses embodiments of the CO- PLAY primarily within the context of video gaming applications. However, it is to be understood that the system described herein may be readily configured/ customized for a wide range of other applications or implementations. For example, aspects of the CO- PLAY may be adapted for cryptographic communications, artificial intelligence simulations, remote access presentation and/or the like. It is to be understood that the CO-PLAY may be further adapted to other implementations for general network management applications and network protocol designs.

[00141] As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further imdescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those imdescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute 1 asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the

2 like are contemplated by the disclosure. As such, some of these features may be

3 mutually contradictory, in that they cannot be simultaneously present in a single

4 embodiment. Similarly, some features are applicable to one aspect of the invention, and

5 inapplicable to others. In addition, the disclosure includes other inventions not

6 presently claimed. Applicant reserves all rights in those presently unclaimed inventions ? including the right to claim such inventions, file additional applications, continuations,

8 continuations in part, divisions, and/or the like thereof. As such, it should be

9 understood that advantages, embodiments, examples, functional, features, logical,0 organizational, structural, topological, and/or other aspects of the disclosure are not to1 be considered limitations on the disclosure as defined by the claims or limitations on2 equivalents to the claims.