Source: http://www.patentsencyclopedia.com/app/20080307096
Timestamp: 2018-02-25 14:38:37
Document Index: 184078653

Matched Legal Cases: ['art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500']

Using a remote handheld device as a local device - Patent application
Patent application title: Using a remote handheld device as a local device
Inventors: Jian Wang (Beijing, CN) Yang Li (Beijing, CN) Yang Li (Beijing, CN) Lifeng Wang (Beijing, CN) Chao Li (Beijing, CN)
Patent application number: 20080307096
Using a remote handheld device as a local device - Patent application <?php require_once('/home/patents/php/mtc.config.php'); require_once('/home/patents/php/mtc.class.php'); $MTC = new MTC(); $MTC->init(); ?>
Inventors: Jian Wang Lifeng Wang Yang Li Chao Li
A data connection can be established between a handheld device (e.g., a mobile phone or smartphone) and a computerized second device. For example, an action associated with a keyboard scancode can be mapped to a key on the keypad of the handheld device. A key press on a keypad of the handheld device can be translated into key press data. The key press data can be sent to the second device over the data connection, causing the action to be executed on the second device.
1. A method of aggregating a computerized handheld device and a computerized second device, said method comprising:establishing a data connection between said handheld device and said second device, wherein said handheld device provides mobile phone capability and wherein said establishing comprises automatically selecting a connection interface from a plurality of connection interfaces;translating a key press on a keypad of said handheld device into key press data, said translating comprising mapping an action associated with a keyboard scancode to a key on said keypad of said handheld device; andsending said key press data to said second device over said data connection to cause execution of said action on said second device.
2. The method of claim 1 wherein said handheld device is selected from the group consisting of: a personal digital assistant; a smartphone; a mobile phone.
3. The method of claim 1 wherein said mapping is selected from a plurality of user-defined mappings resident on said handheld device.
4. The method of claim 1 wherein said connection interface has the highest bandwidth among said plurality of connection interfaces.
5. The method of claim 1 further comprising:receiving image data from said second device via said data connection; andrendering said image data on a display of said handheld device, wherein said rendering shows a result of executing said action on said second device.
6. The method of claim 1 further comprising sending image data captured by a camera of said handheld device to said second device via said data connection.
7. The method of claim 1 further comprising mapping a sensed position of an object relative to a touchpad of said handheld device into an action executed on said second device.
8. The method of claim 1 further comprising said handheld device automatically detecting said second device.
9. The method of claim 1 wherein said handheld device is associated with a user-defined group and a password that allow said handheld device to connect with said second device.
10. A computer-readable medium having computer-executable components for aggregating a computerized handheld device and a computerized second device, said components comprising:a user interface that associates a key press on a keypad of said handheld device with a first code, wherein said handheld device has cell phone capability;a key press simulator coupled to said user interface that associates said first code with a keyboard scancode; anda connection manager coupled to said key press simulator that establishes a data connection between said handheld device and said second device, wherein said connection manager automatically selects a connection interface from a plurality of connection interfaces according to an attribute of said connection interfaces, and wherein said scancode is sent to said second device via said data connection to cause execution of a corresponding action on said second device.
11. The computer-readable medium of claim 10 wherein said key press simulator comprises a plurality of user-defined mappings, each of said mappings associating a code generated by a key press on said keypad with a keyboard scancode, and wherein a code generated by a single key press on said keypad is associated with a combination of multiple keyboard scancodes.
12. The computer-readable medium of claim 10 further comprising a device manager coupled to said connection manager, wherein said device manager accepts a request from said second device to use said keypad as an input device, and wherein said device manager refuses other such requests until said data connection is closed.
13. The computer-readable medium of claim 10 further comprising a device manager coupled to said connection manager, wherein said device manager acquires image data captured by a camera of said handheld device and forwards said image data to said connection manager, which forwards said image data to said second device.
14. The computer-readable medium of claim 10 wherein said key press simulator also associates proximity of an object to a touchpad of said handheld device into an action that is executable on said second device.
15. A computer-readable medium having computer-executable components for aggregating a smartphone and a computerized second device, said components comprising:a first virtual device driver;a virtual bus driver coupled to said first virtual device driver; anda connection manager coupled to said virtual bus driver, wherein said connection manager automatically detects said smartphone and also automatically selects a connection interface from a plurality of connection interfaces to establish a data connection between said second device and said smartphone, wherein said virtual bus driver transfers first data received via said data connection to said first virtual device driver, and wherein said first data comprises a keyboard scancode generated from a key press on a keypad of said smartphone.
16. The computer-readable medium of claim 15 further comprising a second virtual device driver coupled to said virtual bus driver, wherein said virtual bus driver transfers second data received via said data connection to said second virtual device driver, and wherein said second data comprises image data captured by a camera of said smartphone.
17. The computer-readable medium of claim 15 further comprising a third virtual device driver coupled to said virtual bus driver, wherein said virtual bus driver transfers third data received via said data connection to said third virtual device driver, and wherein said third data comprises a code generated in response to an object in proximity to a touchpad of said smartphone.
18. The computer-readable medium of claim 15 further comprising a user interface coupled to said connection manager, wherein said user interface displays information indicating said smartphone has been detected.
19. The computer-readable medium of claim 15 wherein said keyboard scancode causes an action to be executed on said second device, wherein said second device sends image data to said smartphone via said data connection, and wherein said image data when rendered on a display device of said smartphone shows a result of executing said action on said second device.
20. The computer-readable medium of claim 15 wherein said virtual device driver, said virtual bus driver and said connection manager are receptive to information received from said smartphone via said data connection when said second device is in a sleep state such that a signal from said smartphone awakens said second device.
[0001]Conventional computing devices enable users to enter inputs and interact with the computer in different ways. For example, an alphanumeric keyboard or a cursor control device (e.g., a mouse) can be used to indicate a choice or to input data. These types of input devices are both convenient and familiar to most users. Wireless versions of these input devices can be even more convenient, by eliminating the need for cables that connect one device to another.
[0002]Still, wireless keyboards remain relatively bulky. Also, many of today's households have more than one computer, each with its own keyboard and mouse. There are advantages to using one keyboard and one mouse to control all of the household's computers, but this can be problematic when situations arise in which different users want to use the computers at the same time.
[0003]A data connection can be established between a handheld device (e.g., a mobile phone or smartphone) and a computerized second device. An action associated with a keyboard scancode can be mapped to a key on the keypad of the handheld device. A key press on a keypad of the handheld device can be translated into key press data. The key press data can be sent to the second device over the data connection, causing the action to be executed on the second device. In this manner, the handheld device can be used to simulate the local keyboard of, for example, a personal computer. In an analogous manner, other features of the handheld device can be used to simulate a mouse or a local camera.
[0005]The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments and, together with the description, serve to explain the principles of the embodiments:
[0006]FIG. 1 is a block diagram showing a handheld device and another device in one embodiment.
[0007]FIG. 2 is a block diagram showing computer-executable components implemented on a handheld device in one embodiment.
[0008]FIG. 3 is a block diagram showing computer-executable components implemented on a computer in one embodiment.
[0009]FIG. 4 is a block diagram showing computer-executable components that can be implemented on either or both an aggregated handheld device and a computer in one embodiment.
[0010]FIG. 5 is a flowchart of one embodiment of a method for aggregating a handheld device and another device.
[0011]Some portions of the detailed descriptions which follow are presented in terms of procedures, logic blocks, processing and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. In the present application, a procedure, logic block, process, or the like, is conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, although not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system.
[0012]It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present application, discussions utilizing the terms such as "establishing," "selecting," "translating," "mapping," "sending," "executing," "receiving," "rendering," "detecting," "associating" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[0013]Embodiments described herein may be discussed in the general context of computer-executable instructions residing on some form of computer-usable medium, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or distributed as desired in various embodiments.
[0014]By way of example, and not limitation, computer-usable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disk ROM (CD-ROM), digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information.
[0015]Communication media can embody computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
[0016]FIG. 1 is a block diagram showing a computerized handheld device 100 and a computerized second device 150 in communication with each other. Handheld device 100 may be, for example, a smartphone, a personal digital assistant, a cell phone or mobile phone, or the like. Handheld device 100 incorporates some form of alphanumeric keypad. Handheld device 100 may also incorporate some form of a display device (e.g., a display screen). In some types of handheld devices, the display screen can function as a touchpad or touch screen--that is, for example, an object such as a stylus, a pen, a probe or a user's fingertip can be pressed (touched) against the display screen, or brought within sensing range of the touchpad, causing an action that is associated with the position of the object (relative to the touchpad) to be performed. Handheld device 100 may also incorporate a digital camera.
[0017]Second device 150 is some type of personal computer (PC) system, such as a desktop, laptop or notebook PC. Generally speaking, handheld device 100 and second device 150 each incorporate at least one processing unit and a memory. Depending on the exact configuration and type of computing device, the memory may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. The devices 100 and 150 may each also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. The devices 100 and 150 each also include some form of communications connection(s) that allow the device to communicate wirelessly with other devices and with each other using, for example, an Infrared Data Association (IrDA), Bluetooth® or WiFi® connection interface. Alternatively, devices 100 and 150 can communicate with each other using a wired connection interface such as a universal serial bus (USB) or Ethernet connection interface.
[0018]In the example of FIG. 1, a key press on the keypad of the handheld device 100 is translated into key press data. More specifically, when a key on the handheld device 100 is pressed, the code associated with that key is translated into a keyboard scancode. Because a keypad on a handheld device generally has fewer keys than a standard PC keyboard, the keys on the handheld device 100 are mapped to a subset of the set of scancodes that are typically associated with a standard keyboard. In this manner, certain actions, each of which is associated with a particular keyboard scancode, can be mapped to respective keys on the keypad of the handheld device 100, and vice versa.
[0019]A key on the handheld device 100 may be mapped to a single key (or scancode) on a standard keyboard, or a key on the handheld device 100 may be mapped to multiple keys (scancodes) on a standard keyboard. In the latter instance, a single key press on the handheld device 100 can simulate the pressing of a combination of multiple keys on a standard keyboard, such as "Alt+Tab" or "Ctrl+Alt+Del."
[0020]A default mapping of the handheld device's keypad to a standard keyboard may be used. Alternatively, a user may define a customized mapping. Furthermore, a user can define multiple customized mappings, such that one mapping is used with one application and another mapping with another application.
[0021]Key press data can be sent, via the data connection, from the handheld device 100 to the second device 150. The second device 150 can then execute the action dictated by the key press data. In one embodiment, the second device 150 sends image data (e.g., for a thumbnail image) to handheld device 100, allowing the user to view, on the handheld device's display, the result of the action that was executed.
[0022]Continuing with reference to FIG. 1, image data (e.g., for still pictures or videos) can also be sent from the handheld device 100 to the second device 150. More specifically, image data can be captured by a camera on handheld device 100 and sent to second device 150. In this manner, the camera on handheld device 100 can be used as a local camera for second device 150.
[0023]Also, touchpad data can be sent from the handheld device 100 to the second device 150. More specifically, as mentioned above, handheld device 100 can include a touchpad (e.g., a capacitance sensor) that is able to detect an object (e.g., a user's finger, a stylus, a pen, a probe or the like) that is within sensing range of or in contact with the touchpad. The sensed position of the object relative to the touchpad can be conventionally translated into an action that is executed by the handheld device 100. According to one embodiment, the sensed position of the object can also be translated into a code that can be mapped to an action executable by the second device 150. The code can be transmitted from the handheld device 100 to the second device 150, which can then execute the action dictated by the code. In a manner similar to that described above, the second device 150 can send image data (e.g., a thumbnail) to the handheld device 100, allowing the user to view, on the handheld's display, the result of the executed action.
[0024]Thus, moving a stylus or a finger across or over the surface of a touchpad (which may be incorporated within the display screen) on the handheld device 100 can result in a scrolling type of action on the second device 150. Also, touching a computer graphic (e.g., a simulated button) on the touchpad or display screen of the handheld device 100 can result in an action being executed on the second device 150. In addition, a touch to the touchpad on handheld device 100 can be translated into a mouse click on second device 150. Accordingly, handheld device 100 can be used as a local cursor control device (e.g., mouse) for the second device 150.
[0025]In one embodiment, communication between the handheld device 100 and the second device 150 is subject to security constraints. For example, a user can define a group of devices, and only devices that are members of that group can discover and connect with the second device 150. A password may also be used.
[0026]FIG. 2 is a block diagram showing computer-executable components implemented on a handheld device 100 in one embodiment. In the example of FIG. 2, these components include user interface 205, key press simulator 210, device manager 220, and connection manager 225. Although these components are illustrated as separate entities for purposes of discussion, in practice they may or may not be implemented as such. In other words, the functions performed by these components can be performed (perhaps with other functions) using software configured differently than that illustrated in FIG. 2.
[0027]In one embodiment, with reference also to FIG. 1, user interface 205 receives the code generated when a key on the handheld device's keypad is pressed, and passes that code to the key press simulator 210. In another embodiment, via connection manager 225, user interface 205 also receives and renders image data sent from the second device 150, so that actions that are executed on the second device can be viewed on a display screen of the handheld device 100.
[0028]In one embodiment, the key press simulator 210 (in conjunction with user interface 205) allows a user to customize the mapping of the keypad on the handheld device 100 to the scancodes of a standard PC keyboard. Utilizing either a customized mapping or a default mapping, the key press simulator 210 also translates the code generated when a key is pressed on the handheld device's keypad into a keyboard scancode. As noted above, a single code (associated with a single key press on the handheld device's keypad) can be translated into a combination consisting of multiple scancodes.
[0029]In one embodiment, device manager 220 receives and manages a request from the second device 150 to make the handheld device's keypad the local keyboard of the second device. In one embodiment, after device manager 220 accepts such a request, any request to make the handheld device's keypad the local keyboard of another device is refused. Once the remote keypad of the handheld device 100 is no longer to be used as a local keyboard for the second device 150, the data connection between the handheld device and the second device is closed, and the handheld device is then open to requests from other devices.
[0030]In a similar manner, device manager 220 can also receive and manage a request from the second device 150 to make the handheld device act as the local mouse of the second device, and can also receive and manage a request from the second device to make the handheld device's camera the local camera of the second device. In general, the same software architecture can be used to share the features (e.g., keypad, camera, etc.) of the handheld device 100 with the second device 150.
[0031]In one embodiment, connection manager 225 provides an inter-process communication (IPC) mechanism between networked processes on handheld device 100 and second device 150. Connection manager 225 also can provide connection application program interfaces (APIs) that allow the handheld device 100 and the second device 150 to establish a data connection and communicate with each other (that is, the data connection is bi-directional). Knowledge of the type of connection interface (e.g., Ethernet, WiFi®, Bluetooth®, USB, IrDA) being used is not required.
[0032]In the present embodiment, a connection manager is used on both the handheld device 100 and the second device 150. The connection managers on the handheld device 100 and the second device 150 provide similar functionality, including functionality that allows these devices to automatically discover (detect) each other, communicate with each other, and monitor the state of the data connection. The connection managers are described in more detail in conjunction with FIG. 4, below.
[0033]FIG. 3 is a block diagram showing computer-executable components implemented on a computer (e.g., second device 150 of FIG. 1) in one embodiment. In the example of FIG. 3, these components include user interface 305, virtual device manager 310, connection manager 325, virtual bus driver 335 and virtual device drivers 340. Although these components are illustrated as separate entities for purposes of discussion, in practice they may or may not be implemented as such. In other words, the functions performed by these components can be performed (perhaps with other functions) using software configured differently than that illustrated in FIG. 3.
[0034]In one embodiment, with reference also to FIG. 1, user interface 305 can be used to display a list of handheld devices within communication range of the second device 150. User interface 305 also provides a mechanism that allows a user to select one of the handheld devices to be used as, for example, the local keyboard, mouse or camera for second device 150.
[0035]In general, connection manager 325 performs functions similar to those performed by connection manager 225 of FIG. 2, except on behalf of second device 150. Connection manager 325 is described in more detail in conjunction with FIG. 4.
[0036]In one embodiment, and continuing with reference to FIGS. 1 and 3, virtual device manager 310 sends a request to the handheld device 100 to make the handheld device's keypad the local keyboard of the second device 150. If the request is accepted, then virtual device manager 310 requests the virtual bus driver 335 to "plug in" a virtual device driver 340 that represents the handheld device's keypad as the local keyboard.
[0037]Virtual bus driver 335 has the capability to manage multiple virtual devices. Thus, virtual device manager 310 can also send requests to the handheld device 100 to make the handheld device act as the local mouse of the second device 150 and to make the handheld device's camera the local camera of the second device. In general, the same software architecture can be used to allow the features (e.g., keypad, camera, etc.) of the handheld device 100 to be shared with the second device 150. If any of the requests are accepted, then virtual device manager 310 requests the virtual bus driver 335 to plug in the appropriate virtual device driver 340.
[0038]The virtual device drivers 340 for the keyboard and mouse functions forward data to the operating system as the data is received. In contrast, image data received from the handheld device 100 may be buffered by virtual device manager 310 or by the appropriate virtual device driver 340, in order to accumulate a frame of data before the data is sent to the appropriate application. Support is provided for WIN32 APIs including video capture devices such as DirectShow®.
[0039]In general, virtual device drivers 340 each represent a virtual device (that is, a device that does not have local hardware on second device 150, such as the handheld device's keypad) as a real (physical) device to the operating system of second device 150. When, for example, key press data is received from handheld device 100, the virtual device manager 310 sends that data to the virtual bus driver 335, which in turn sends the data to the appropriate virtual device driver 340. Once the keypad of the handheld device 100 is no longer to be used as the local keyboard, the virtual device manager 310 requests the virtual bus driver 335 to "unplug" the virtual device driver 340 that represents the handheld device's keypad and also sends a request to the handheld device 100 to close the data connection with the second device 150. In a similar manner, other features of the handheld device 100 (e.g., the camera, or the cursor control function) can be unplugged from the appropriate virtual device driver 340.
[0040]In a conventional sense, a bus has hardware support, and devices connected to the bus are designed according to the bus requirements and have local hardware. However, a virtual device such as the keypad of handheld device 100 does not have local hardware (relative to second device 150). Virtual bus driver 335 controls a virtual bus that is represented to an operating system and to other applications as a conventional hardware bus (e.g., a PCI bus, AGP bus or USB). The virtual bus connects and manages virtual devices, permitting virtual devices that do not have local hardware to connect with the second device 150 in a Plug and Play (PnP) manner.
[0041]To plug a virtual device into a virtual bus using PnP, virtual bus driver 335 first receives a request to plug in the device. The virtual bus driver 335 creates a child physical device object (PDO) for the virtual device and adds the virtual device to a local device list. A PnP manager sends a PnP input/output request packet (IRP) to the virtual bus to query the updated device list, and the virtual bus driver 335 responds with a list of attached devices. By comparing the updated list with the previous list, the operating system is made aware of the presence of a new, connected device. The PnP manager sends a series of PnP events to the virtual bus in order to obtain information about the new device, and the virtual bus driver 335 responds with the device information. The operating system then loads the appropriate virtual device driver 340 based on the device information. The virtual device is now ready for use and can send and receive information similar to other local devices. When a virtual device is removed, the PnP manager sends a series of PnP events to the virtual bus driver 335 and the appropriate virtual device driver 340. The virtual bus driver 335 responds by removing the device's PDO from the device list.
[0042]In one embodiment, the virtual device drivers 340, the virtual bus driver 335, and the connection manager 325 are part of a service that may be started automatically before the operating system is logged on. Thus, second device 150 can be controlled from handheld device 100 before the operating system on the second device is logged on. These elements are also receptive to information received from the handheld device 100 when the second device 150 is in a sleep state (e.g., a low power mode), such that a signal from the handheld device sent over the data connection will awaken the second device.
[0043]FIG. 4 is a block diagram showing computer-executable components of a connection manager 425 that is analogous to the connection managers 225 and 325 of FIGS. 2 and 3, respectively. In the example of FIG. 4, the connection manager 425 includes connection APIs 410, channel manager 420, and host manager 430. Although these components are illustrated as separate entities for purposes of discussion, in practice they may or may not be implemented as such. In other words, the functions performed by these components can be performed (perhaps with other functions) using software configured differently than that illustrated in FIG. 4.
[0044]In the present embodiment, connection manager 425 hides the details of the underlying physical mediums and topologies, and provides unified APIs that allow devices to communicate with each other seamlessly and transparently. In one embodiment, the connection APIs 410 include a set of functions that can be called by applications. These functions include, but are not limited to, functions that: initialize the connection manager; release resources associated with the connection manager; create a virtual named channel; destroy a virtual named channel; wait for an incoming connection to a virtual named channel and open a channel instance on the virtual named channel; close a channel instance and the connection; connect to a virtual named channel; disconnect from a virtual named channel; read data from a virtual named channel instance; write data to a virtual named channel instance; enumerate available virtual named channels by name; and retrieve information (e.g., channel name, properties, and endpoint address) about a virtual named channel.
[0045]A virtual named channel is a named, duplex communication channel. All instances of a virtual named channel share the same pipe name, but each instance has its own buffer and handle and provides a separate conduit for communication between devices. A virtual named channel can be viewed as a server that can be connected to one or more clients. In the present embodiment, the virtual named channels are managed by channel manager 420, which also manages the mapping between virtual named channel instances and underlying sockets, controls how data is received or sent over a virtual named channel, and handles exceptions and errors on virtual named channels.
[0046]In the present embodiment, host manager 430 handles the details of discovering available devices and resolves network addresses of such devices. In one embodiment, channel manager 420 chooses a connection interface, from among a number of available connection interfaces, based on a measurable attribute of the connection interfaces. In general, the "best" connection interface among those available is chosen. For example, the connection interface having the greatest bandwidth may be chosen.
[0047]FIG. 5 is a flowchart 500 of one embodiment of a method for aggregating a handheld device and another device. Although specific steps are disclosed in flowchart 500, such steps are exemplary. That is, various other steps or variations of the steps recited in flowchart 500 can be performed. The steps in flowchart 500 may be performed in an order different than presented. Furthermore, the features of the various embodiments described by flowchart 500 can be used alone or in combination with each other. In one embodiment, flowchart 500 can be implemented by handheld device 100 (FIG. 1) as computer-readable program instructions stored in a memory unit and executed by a processor.
[0048]In block 510 of FIG. 5, a data connection between a computerized handheld device (e.g., a smartphone, PDA or mobile phone) and a computerized second device (e.g., a PC) is established. In one embodiment, a connection interface (e.g., Ethernet, WiFi®, Bluetooth®, USB, IrDA) is automatically selected from a number of connection interfaces.
[0049]In block 520, in one embodiment, a key press on a keypad of the handheld device is translated into key press data that maps an action associated with a keyboard scancode to a key on the keypad of the handheld device.
[0050]In block 530, in one embodiment, the key press data is sent to the second device over the data connection, and the second device then executes the action after disposition of the key press data.
[0051]In block 540, in one embodiment, image data is sent over the data connection from the second device to the first device. The image data may or may not be compressed. The image data, when displayed, shows on the handheld device a result associated with the action being executed on the second device.
[0052]In another embodiment, image data captured by a camera on the handheld device can be sent to the second device. In yet another embodiment, the handheld device can be used as, for example, a mouse for the second device.
[0053]In summary, according to embodiments described herein, a feature (e.g., a keypad or camera) of a remote handheld device (e.g., a smartphone) can be used as a local device (e.g., a keyboard, mouse or Webcam) on a second device (e.g., a PC). Thus, for example, in households in which there are multiple PCs, a single keyboard and mouse can be used to control all of the PCs--because more and more people regularly carry or have access to mobile phones and the like, if a situation arises in which different users want to use the PCs at the same time, one user can use the conventional keyboard and mouse, while other users can use their handheld devices as keyboards and mice. Because thumbnail images of what transpires on the PC can be sent to the handheld devices, users can be some distance away from the PC they are controlling (the distance would depend on the type of connection interface in use).
[0054]In addition to other advantages mentioned herein, embodiments described herein are extensible to new types of connection interfaces and new features of handheld devices (in other words, new types of virtual devices).
[0055]In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is, and is intended by the applicant to be, the invention is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Hence, no limitation, element, property, feature, advantage, or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Patent applications by Chao Li, Beijing CN
Patent applications by Lifeng Wang, Beijing CN
20100088287 INFORMATION SYSTEM, METHOD AND RECORDING MEDIUM HAVING PROGRAM RECORDED THEREON RELATING TO COLLECTIVELY REGISTERED DATA
20100088286 DEPLOYMENT MANAGER FOR MASTER DATA MANAGEMENT
20100088285 NDMA SCALABLE ARCHIVE HARDWARE/SOFTWARE ARCHITECTURE FOR LOAD BALANCING, INDEPENDENT PROCESSING, AND QUERYING OF RECORDS
20100088284 ARCHIVING SYSTEM FOR MASSIVE DATABASES USING PRE-COMPUTED DATA LIFECYCLES
20100088283 SYSTEM AND METHOD FOR MANAGING DATABASE APPLICATIONS
2012-01-19 Facilitating network communications with control server, hosting server, and devices utilizing virtual network connections
2012-01-12 Method and apparatus for calculating a probable throughput for a location based at least in part on a received throughput
2012-01-19 Monitoring system and method for connecting a monitoring device to a service server
2009-08-20 Using mobile device to create activity record
2011-09-01 Computer to handheld device virtualization system