Method and Apparatus for Binding Mobile Device Functionality to an Application Definition

Abstract

In one embodiment, a mobile device renders a page on a screen thereof in response to the mobile device receiving a serialized page definition via a wireless communication link from a server implementing a CRM. The serialized page definition comprises first data and a first command that is bound to the first data. The mobile device is configured to implement a first function when the first command is invoked by a user. The mobile device implements the first function in response to user invocation of the first command, wherein the first function is implemented using the first data.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Provisional Application No. 61/384,150; filed on Sep. 17, 2010, and is incorporated herein in its entirety by reference.

BACKGROUND

Enterprise applications are integral parts of many businesses and provide valuable services to its users. For example, enterprise applications provide customer relationship management (CRM), resource planning, human resource management, etc. The present invention will be described with reference to a CRM that provides sales and marketing services to its users, it being understood that the present invention should not be limited thereto.

CRM is a widely implemented strategy for managing a company's interaction with customers, clients, and sales prospects. CRM involves technology to organize, automate, and synchronize business processes-principally sales activities, but also those for marketing, customer service, and technical support. The overall goals of CRM are to find, attract, and win new clients, nurture and retain those the company already has, etc.

CRM services can be accessed by employees of a company via a desktop computer system that is coupled via a network to a data processing system. CRM services can also be accessed through mobile devices (e.g., smart phones or tablet computers). The present invention will be described with reference to providing CRM related services to users via their mobile devices, it being understood that the present invention should not be limited thereto.

SUMMARY

In one embodiment, a mobile device renders a page on a screen thereof in response to the mobile device receiving a serialized page definition via a wireless communication link from a server implementing a CRM. The serialized page definition comprises first data and a first command that is bound to the first data. The mobile device is configured to implement a first function when the first command is invoked by a user. The mobile device implements the first function in response to user invocation of the first command, wherein the first function is implemented using the first data.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

FIG. 1 graphically illustrates relevant components of an example system that employs a CRM.

FIG. 2 graphically illustrates an example of the server in FIG. 1.

FIG. 3 graphically illustrates external components of an example mobile device employed in FIG. 1.

FIG. 4 graphically illustrates external components of an example mobile device employed in FIG. 1.

FIG. 5 graphically illustrates internal components of an example mobile device employed in FIG. 1.

FIG. 6 graphically illustrates internal components of an example mobile device employed in FIG. 1.

FIG. 7 illustrates example action entries of a page definition corresponding to the page displayed by the mobile device of FIG. 3 or FIG. 4.

FIG. 8 illustrates relevant aspects a process implemented by the system shown in FIG. 1.

FIG. 9 is a block diagram of an example computer system that may be employed in the system of FIG. 1 or 4.

The use of the same reference symbols in different drawings indicates similar or identical items.

DETAILED DESCRIPTION

Today's sales and marketing workforce is more mobile than ever. To reduce sales downtime, increase customer face time, and win more deals, many companies now employ mobile CRM to move their business forward while employees are on the road. Mobile CRM enable users to more efficiently use CRM services such accessing, reviewing, and/or updating sales opportunities, contacts, leads, calendar entries, etc.

FIG. 1 illustrates in block diagram form, relevant components of an example system 100 that provides mobile CRM. System 100 includes mobile devices (e.g., smart phones) 102 and 104 in wireless communication with a CRM executing on server 106. Services provided by the CRM can be accessed via user interfaces (hereinafter also referred to as pages) sent by server 106 and displayed by mobile devices 102 or 104. As will be more fully described below, the CRM operates with mobile devices 102 and 104, which are substantially different in design and operation. In other words, the CRM is designed to be mobile device independent.

The CRM implements a model-view-controller architecture. The CRM includes a single, metadata driven application that contains multiple page definitions. In response to receiving a page request from mobile device 102 or 104, the CRM merges a selected page definition with data of a logical data model, the result of which is serialized and sent to the mobile device 102 or 104 as a reply to its request. Mobile device 102 or 104 receives the reply and displays a corresponding page that includes visual representations of the merged data. The page can be displayed with a look and feel that is native to the mobile device 102 or 104.

The CRM executing on server 106 is in data communication with a storage system 112 that includes one or more relational databases 116, which in turn store data of business objects of a logical data model. A business object may represent a logical entity that stores a set of instance variables or properties, also known as attributes, and associations with other business objects, thereby weaving a map of objects representing business relationships. A business object may represent a data entity that may contain related data held in many tables of the relational database 116. A business object may be made of business components that map to these tables. A business object is an object type that glues related business components together. A business component is said to provide a layer of wrapping over the tables. Opportunities, accounts, and contacts are examples of business objects.

FIG. 2 illustrates an example of server 106 from FIG. 1 with relevant components shown in block diagram form. Memory 202 stores a single, metadata driven application definition for the CRM. The application includes page definitions, some of which are visually represented along with navigation flow relationships therebetween. Page definitions (also known as “views”) define pages that are displayed by mobile devices 102 or 104. The application definition, including page definitions, can be built using Java Server Faces (JSF) technology, it being understood the present invention should not be limited thereto. JSF defines a standard framework of components for building components, including page definitions. JSF can also be used to define page navigation within the application definition, map page components to a data model, etc. While page definitions run on server 106, they are displayed on mobile devices 102 or 104 after serialization and subsequent transmission. Example page definitions are visually represented in memory 202. The “springboard” page definition can be used to render a page with icons arranged in a two-dimensional pattern. Each icon may represent a mini-application or high level business object within the logical data model. The “accounts,” “opportunities,” and “contacts” page definitions can be used to render pages with names or other information of accounts, opportunities, and contacts, respectively, in a list pattern. The “account,” “opportunity,” and “contact” page definitions can be used to render pages with data from an account, opportunity, and contact, respectively, in a form pattern. The “account form,” “opportunity form,” and “contact form” page definitions can be used to render pages with data from an account, opportunity, and contact, respectively, in a user editable form pattern. Other page definitions in memory 202 are contemplated.

With continuing reference to FIG. 2, server 106 includes a logical data model 204. Page definitions can be used to render logical data model 204 into a form suitable for interaction by a user via mobile device 102 or 104. Multiple page definitions can exist for a single logical data model 204 for different purposes. Logical data model 204 manages the data of the application definition, responds to requests for information about its state (usually from a page definition), and responds to instructions to change state from control logic 206. In one sense, logical data model 204 provides access to business objects such as contacts, opportunities, analytics, etc., or other information such as identities of business objects. The logical data model 204 is both the data and the business/domain logic needed to manipulate the data of the application definition.

Control logic 206, which may take form in instructions executing on a processor, is in data communication with the application definition contained within memory 202 in addition to being in data communication with interface 210 and serialization system 212. Control logic 206 accepts data input from a user via mobile device 102 or 104 and instructs the logical data model 204 to perform actions (e.g., updating an opportunity) based on that data input. In response to receiving a page request from mobile device 102 or 104 via interface 210, control logic 206 may access the application definition in memory 202 to identify and retrieve a copy of the page definition, or relevant components thereof, which is needed to form the requested page. The page definition retrieved from memory 210 may contain metadata that binds the page definition to the logical data model 212 for data needed in the requested page. Control logic 206 can make calls on business objects of logical data model 204 to retrieve the data of interest. The page definition is merged with data from model 204, the result of which is serialized by serialization system 212 and subsequently transmitted to the requesting mobile device in a reply. Ultimately, the requesting mobile device receives the reply, deserializers its content, and displays a corresponding page on a screen. FIGS. 3 and 4 illustrate example pages that are displayed by mobile devices 102 and 104, respectively.

As will be more fully described, users can invoke functions of the mobile devices such as cell phone, email, mapping, etc., via displayed pages such as those shown in FIGS. 3 and 4. Mobile device functionality (e.g., cell phone, email, etc.) is bound to components of the displayed page via commands in the serialized page definition sent to the mobile device.

In addition to illustrating example pages of the CRM, FIGS. 3 and 4 illustrate relevant external features of mobile devices 102 and 104. Mobile devices 102 and 104 are distinct in design and operation. Mobile device 102 includes a hard or physical keyboard, while mobile device 104 includes a soft keyboard (not shown). Mobile device 104 may include soft buttons displayed on a touch sensitive display screen. Mobile device 102 lacks a touch sensitive screen. Rather, mobile device 102 includes a track ball and physical buttons. For purposes of explanation only, mobile devices 102 and 104 are sized so that they can fit in the front or back pocket of a normal pair of adult sized pants, it being understood that the present invention can find application with respect to larger devices such as tablet computers.

With continuing reference to FIG. 2, mobile device 102 as shown in FIG. 3 includes a screen 302 that displays an “Opportunity” page 300. In addition, mobile device 102 includes physical buttons 310-316, a trackball 318, and a physical keyboard 320. A trackball is a pointing device consisting of a ball held by a socket containing sensors to detect a rotation of the ball about two axes—like an upside-down mouse with an exposed protruding ball. The user rolls the ball with the thumb, fingers, or the palm of the hand to move a cursor across screen 302 to reach active buttons like “Call” or “Email.” When the curser reaches an active button displayed on the screen 302, the user can activate the button by depressing trackball 318. This action in turn may implement a command to invoke a mobile device function. Thus, a user can invoke cell phone or email functions of mobile device 102 by activating the Call and Email buttons, respectively.

In contrast, mobile device 104 lacks multiple physical buttons and a physical keyboard. Mobile device 104 has one physical button 402 and a touch sensitive display screen 402. In FIG. 4 mobile device 104 displays an “Opportunity” page 400 that corresponds to the Opportunity page 300 shown in FIG. 3. Page 300 includes several soft buttons 406-412. A user can activate any of soft buttons 406-412 simply by touching it. Although not shown, a soft keyboard is displayed on screen 404 when the user, for example, activates edit button 408. A user can activate a button simply by touching it. This action in turn may implement a command to invoke a mobile device function. Thus, a user can invoke cell phone or email functions of mobile device 102 by activating the Call and Email buttons 410 and 412, respectively.

FIGS. 5 and 6 illustrate relevant internal components of the mobile devices 102 and 104, respectively, in block diagram form. With continuing reference to FIG. 3, mobile device 102 of FIG. 5 includes a memory controller 502 coupled to a processor 504 and a peripherals interface 506. The various components of mobile device 102 may be coupled by one or more communication buses or signal lines 508. The peripherals interface 506 is coupled to radio frequency (RF) circuit 510, audio circuit 512, and global positioning system (GPS) circuit 513. The GPS circuit 513 supports a location determining capability and can provide the longitude and latitude of mobile device 102 upon request.

The peripherals interface 502 is coupled to an I/O subsystem 514 that contains various controllers that interact with other components of mobile device 102. I/O subsystem 514 includes a keyboard controller coupled to receive input from the physical keyboard 320. The track ball controller is coupled to receive input from the trackball 318. And dedicated buttons controllers receive respective inputs from dedicated buttons 310-316.

Memory controller 502 is coupled to memory 518, which may take form in one or more types of computer readable medium. Memory 518 stores several software components or modules including a communication module that provides communication procedures, which enable communication between mobile device 102 and server 106 via a wireless communication link. Memory 518 may also include a software development kit (SDK) 522, an operating system 524, and a set of applications including CRM client 526 as shown. Other components in memory 518 may support email, texting, mapping, etc. The CRM client 526, as will be more fully described below, operates in conjunction with other modules (e.g., operating system 524, etc.) shown within FIG. 5 to render a page provided by server 106, create a request for a subsequent page, issue instructions to initiate functions such as email, cell phone, etc.

With continuing reference to FIG. 4, mobile device 104 of FIG. 6 includes a memory controller 602 coupled to a processor 604 and a peripherals interface 606. Like mobile device 102, the various components of mobile device 104 may be coupled by one or more communication buses or signal lines 608. The peripherals interface 606 is coupled to RF circuit 610, audio circuit 612, and global positioning system (GPS) circuit 613, which supports location determining capabilities.

The peripherals interface 602 is coupled to an I/O subsystem 614 that contains various controllers that interact with other components of mobile device 104. I/O subsystem 614 includes a touch screen controller that is coupled to the touch sensitive display screen 404 shown in FIG. 4. The touch screen controller may detect contact and any movement or break thereof.

Memory controller 602 is coupled to memory 618, which may take form in one or more types of computer readable medium. Memory 618 stores several software components or modules including a communication module that provides communication procedures, which enable communication between mobile device 104 and server 106 via a wireless communication link. Memory 618 may also include an SDK 622, an operating system 624, and a set of applications including CRM client 626 as shown. Other components in memory 618 may support email service, texting, etc. The CRM client 626, as will be more fully described below, operates in conjunction with modules shown within FIG. 6 to display a page provided by server 106, create a request for a subsequent page, issue instructions to initiate functions such as email, cell phone, mapping, etc.

CRM client 626 of mobile device 104 is substantially different than the CRM client 526 of mobile device 102. The differences enable pages requested from the CRM to be displayed with a look and feel that is native to mobile devices 102 and 104, respectively, and similar to the look and feel of pages displayed by other applications in memory 518 and 618. respectively. Look and feel is a term used to describe aspects of page design, including elements such as colors, shapes, layout, and typefaces (the “look”), as well as the behavior of dynamic elements such as buttons, boxes, and menus (the “feel”).

CRM clients 526 and 626 may include expression language (EL) engines (not shown) that can generate distinct sequences of instructions for SDKs 522 and 622, respectively, in response to implementing commands that are bound to components such as buttons of a displayed page. CRM clients 526 and 626 implement the command and issue the instructions in response to user activation of bound buttons. EL instructions when executed invoke a mobile device function such as email, cell phone, etc. Thus, the EL engine of CRM client 526 will generate a sequence of instructions when the user of mobile device 102 activates the Email button of page 300, or the EL engine of CRM client 626 will generate a different sequence of instructions when the user of mobile device 104 activates the email button 412 of page 400.

With continuing reference to FIG. 2, mobile devices 102 and 104 display pages on their respective screens in accordance with serialized page definitions that are received from the CRM of server 106. The page definitions do not take into account the look and feel aspects of mobile devices including mobile devices 102 and 104. In other words, the page definitions are independent of the look and feel of mobile devices 102 and 104. However, corresponding pages (e.g., pages 300 and 400) displayed on mobile devices 102 and 104 are not identical, even though they are created from the same page definition. Many of the differences in corresponding pages may account for differences in the native look and feel of mobile devices 102 and 104. For example, page 400 contains soft “Back” and “Edit” buttons 406 and 408, respectively. Mobile device 104 redisplays an immediately prior page when the Back button is activated. Mobile device 104 displays another page that enables the user to modify data of the current display when the Modify button is activated. Users of mobile device 104 should be more familiar with the Back and Edit buttons and their function if they have previously used other applications that employ the same Back and Edit buttons. Mobile device 102 can implement the same back and edit functions, but these functions are activated in a substantially different way when compared to mobile device 104. Instead of a soft “Back” button, mobile device 102 has a physical “Back” button 314. Mobile device 102 can also implement the function of modifying data, but the modify function is implemented when the user selects an appropriate menu option after a menu is displayed by mobile device 102 in response to the user depressing trackball 318.

Returning to In FIG. 2, computer system 114 is in data communication with page definition editor 214, which in turn is in data communication with page configurations stored within memory 202. An administrator can create and/or modify the pattern definitions stored within memory 202 using page definition editor interfaces displayed on computer system 114. A page definition can be provided for business objects (e.g., accounts, opportunities, leads, etc.) of logical data model 204. The initial page definitions can be subsequently modified using the page definition editor 204.

The application for the CRM can be designed so that users can invoke mobile device functionality (e.g., email, cell phone, etc.) from pages such as the Opportunity pages 300 and 400 shown in FIGS. 3 and 4. During design, developers should have a way to define page definition access to mobile device functionality so that at runtime the definitions are executed. In one embodiment, a developer can define page definition access to mobile device functionality by binding metadata of page definition entries to mobile device functionality. For example, a developer using an interface displayed on computer system 114 can reference a mobile device interface (MDI) within memory 216 in order to bind metadata of entries to mobile device functionality. At run time, these bindings can be interpreted using the MDI. More particularly, during serialization of a page definition, serialization system 212 can interpret a binding for CRM clients (e.g., CRM clients 516 and 616). This approach allows page definitions to drive mobile device functionality. Additionally, this approach allows page definition access to device data such as the longitude and latitude calculated by GPS circuit 513 or 613. A page definition can instruct the mobile device to include its device data (e.g., longitude and latitude) in subsequent requests to server 106. Device data can used to drive page rendering, can be displayed in a page, etc. If a command such as (e.g., <command . . . action=“#{device.phone.call.execute()}” enabled=“#{device.phone.call.enabled}”/>) is sent to the mobile device the command will not be enabled on the mobile device if certain device data indicates the mobile does not support making phone calls, which can happen when the mobile device does not contain a phone or when the phone feature has been selectively disabled by the user. Where the command<inputText label=“Label” value=“#{device.settings[‘aroundme.radius’]”/>is sent to the mobile device, the configured AroundMe radius will be displayed, and if the value is changed, the display will be updated on the mobile device. The page definitions can bind actions to the mobile device; have the mobile device send device data to the CRM; have the mobile device use its device data during a page rendering process; have the device display device data, etc.

Page definitions, when first designed or subsequently modified, can include references to the MDI. Specifically, page definitions can include-entries with metadata bindings that reference entries in the MDI. FIG. 7 illustrates or shows binding entries of an example page definition corresponding to pages 300 and 400 of FIGS. 3 and 4. A binding entry in 702 binds the “email” metadata with an email entry of the MDI. A binding entry 704 binds the “call” metadata with the call entry of the MDI.

During serialization of a page definition, serialization system 212 analyses bindings to determine if they are for functionality of the mobile device. FIG. 8 illustrates a flow chart showing this process in greater detail. More particularly, as shown, when serialization system 212 identifies an binding entry in a page definition, the serialization system determines whether the binding entry is mapped in MDI. If it is not, the binding is presumed to be for functionality that is to be implemented on server 106, such as the creation of a new opportunity or the modification of an existing opportunity. If the serialization system 212 determines that the binding entry is mapped to an entry in MDI, then the binding is for functionality that is implemented on the mobile device. In this situation the binding is translated using the MDI into client commands. For example, in the serialization of the example action entries 702 and 704, serialization system 212 analyzes binding-entries in 702 and 706 and determines the they are mapped in the MDI and should be translated into actionable commands for the CRM clients 526 and 626. FIG. 7 illustrates the serialized “device” commands 706 and 708 that result from the translations of binding entries of 702 and 706, respectively. Command 706 or 708 include data (e.g., JDoe@pinnacle.com, and 214-867-5309) from the logical data model, that is passed to the SDK when the command is implemented on the mobile device. The commands (e.g., device.email.compose.execute CJDoe@pinnacle.com'D can be implemented by CRM client 526 or 626 when the user activates the corresponding Email or Call buttons of pages 300 and 400 of FIGS. 3 and 4. The device command bound to the data, when invoked by the user, can be interpreted by the EL engine executing on the CRM client. In FIGS. 3 and 4, the opportunity pages 300 and 400 were displayed in response to mobile devices 102 and 104, respectively, receiving and deserializing the translated action entries. Specifically, the “Call” and “Email” components are visual representations of the functionality that can be invoked in accordance with the translations shown in FIG. 7. When a user, for example, activates the Call button shown within FIG. 3, CRM mobile 526 generates a sequence of EL instructions to implement the cell phone function of mobile device 102. Moreover, this set of instructions should forward the data (e.g., 214-867-5309) bound to the command. Mobile device 102 requires certain instructions to invoke the cell phone function through use of its SDK, and mobile device 104 would require a different set of instructions to invoke the cell phone function through use of its SDK.

FIG. 9 depicts a block diagram of a computer system 910 suitable for implementing the present disclosure. Computer system 910 may be illustrative of various computer systems (e.g., servers or clients) shown in FIGS. 1 and 2. Computer system 910 includes a bus 912 which interconnects major subsystems of computer system 910, such as a central processor 914, a system memory 917 (typically RAM, but which may also include ROM, flash RAM, or the like), an input/output controller 918, an external audio device, such as a speaker system 920 via an audio output interface 922, an external device, such as a display screen 924 via display adapter 926, serial ports 928 and 930, a keyboard 932 (interfaced with a keyboard controller 933), a storage interface 934, a floppy disk drive 937 operative to receive a floppy disk 938, a host bus adapter (HBA) interface card 935A operative to connect with a Fibre Channel network 990, a host bus adapter (HBA) interface card 935B operative to connect to a SCSI bus 939, and an optical disk drive 940 operative to receive an optical disk 942. Also included are a mouse 946 (or other point-and-click device, coupled to bus 912 via serial port 928), a modem 947 (coupled to bus 912 via serial port 930), and a network interface 948 (coupled directly to bus 912).

Bus 912 allows data communication between central processor 914 and system memory 917, which may include read-only memory (ROM) or flash memory (neither shown), and random access memory (RAM) (not shown), as previously noted. The RAM is generally the main memory into which the operating system and application programs are loaded. The ROM or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with peripheral components. Applications resident with computer system 910 are generally stored on and accessed via a computer readable medium, such as a hard disk drive (e.g., fixed disk 944), an optical drive (e.g., optical drive 940), a floppy disk unit 937, or other storage medium. Additionally, applications can be in the form of electronic signals modulated in accordance with the application and data communication technology when accessed via network modem 947 or interface 948.

Storage interface 934, as with the other storage interfaces of computer system 910, can connect to a standard computer readable medium for storage and/or retrieval of information, such as a fixed disk drive 944. Fixed disk drive 944 may be a part of computer system 910 or may be separate and accessed through other interface systems. Modem 947 may provide a direct connection to a remote server via a telephone link or to the Internet via an internet service provider (ISP). Network interface 948 may provide a direct connection to a remote server via a direct network link to the Internet via a POP (point of presence). Network interface 948 may provide such connection using wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the like.

The operation of a computer system such as that shown in FIG. 9 is readily known in the art and is not discussed in detail in this application. Code for implementing a CRM can be stored in computer-readable storage media such as one or more of system memory 917, fixed disk 944, optical disk 942, or floppy disk 938. Memory 920 is also used for storing temporary variables or other intermediate information during the execution of instructions by the processor 910. The operating system provided on computer system 910 may be MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, Linux®, or another known operating system.

Although the invention has been described in connection with several embodiments. the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.

Claims

1. A method comprising:

a mobile device rendering a page for display on a screen thereof in response to the mobile device receiving a serialized page definition via a wireless communication link, wherein the serialized page definition comprises first data and a first command that is bound to the first data, wherein the mobile device is configured to implement a first function when the first command is invoked by a user;

the mobile device implementing the first function in response to user invocation of the first command, wherein the first function is implemented using the first data.

2. The method of claim 1 further comprising:

a server serializing the page definition in response to the server receiving a request for the page from the mobile device via the wireless communication link, wherein the serializing comprises binding the first command to the first data;

the server sending the serialized page to the mobile device via the wireless communication link.

3. The method of claim 2 wherein the serializing comprises an act of reading the first data from a database in data communication with the server.

4. The method of claim 3 wherein the page definition comprises first metadata bound to a first instruction, wherein the first metadata corresponds to the first data, and the first instruction corresponds to the first command.

5. The method of claim 4 wherein serializing the page definition comprises an act of translating the first instruction into the first command.

6. The method of claim 1 wherein the page comprises a visual representation of the first data.

7. The method of claim 1 wherein the first data comprises an email address, and the first function comprises the mobile device sending an email to the email address.

8. The method of claim 1 wherein the first data comprises a telephone number and the first function comprises the mobile device initiating a telephone call to the telephone number.

9. A computer readable medium comprising executable instructions, wherein a mobile device implements a method in response to executing the instructions, the method comprising:

the mobile device rendering a page for display on a screen thereof in response to the mobile device receiving a serialized page definition via a wireless communication link, wherein the serialized page definition comprises first data and a first command that is bound to the first data, wherein the mobile device is configured to implement a first function when the first command is invoked by a user;

the mobile device implementing the first function in response to user invocation of the first command, wherein the first function is implemented using the first data.

10. The computer readable medium of claim 9 wherein the first data comprises an email address and the first function comprises the mobile device sending an email to the email address.

11. The computer readable medium of claim 9 wherein the first data comprises a telephone number and the first function comprises the mobile device initiating a telephone call to the telephone number.

12. A computer readable medium comprising executable instructions, wherein a method is implemented in response to executing the instructions, the method comprising:

a server serializing a page definition in response to the server receiving a request for a page from a mobile device via a wireless communication link, wherein the serializing comprises binding a first command to first data, wherein the serialized page definition comprises first data and the first command that is bound to the first data, wherein the mobile device can implement a first function corresponding toe the first command;

the server sending the serialized page to the mobile device via the wireless communication link.

13. The computer readable medium of claim 12 wherein the serializing comprises an act of reading the first data from a database in data communication with the server.

14. The computer readable medium of claim 13 wherein the page definition comprises first metadata bound to a first instruction, wherein the first metadata corresponds to the first data, and the first instruction corresponds to the first command.

15. The computer readable medium of claim 14 wherein serializing the page definition comprises an act of translating the first instruction into the first command.

16. A method comprising:

a server serializing a page definition in response to the server receiving a request for a page from a mobile device via a wireless communication link, wherein the serializing comprises binding a first command to first data, wherein the serialized page definition comprises first data and the first command that is bound to the first data, wherein the mobile device can implement a first function corresponding to the first command;

the server sending the serialized page to the mobile device via the wireless communication link.

17. The computer readable medium of claim 16 wherein the serializing comprises an act of reading the first data from a database in data communication with the server.

18. The computer readable medium of claim 17 wherein the page definition comprises first metadata bound to a first instruction, wherein the first metadata corresponds to the first data, and the first instruction corresponds to the first command.

19. The computer readable medium of claim 18 wherein serializing the page definition comprises an act of translating the first instruction into the first command.