CN102130907A - Developer phone registration - Google Patents

Abstract

A technique allows software developers to develop applications for a smart phone or other terminal by unlocking the terminal so that it can run unsigned applications. A developer registers with a web-based service, agrees to registration terms, and provides authentication credentials. Data which verifies the authentication credentials is provided back to the developer's computer. The terminal is connected to the developer's computer, and via a user interface, the developer requests registration of the terminal. In response, the terminal receives the data from the developer's computer, and provides the data and a unique terminal identifier to the service. If authorized, the service returns a persistent token or license which is stored at, and used to unlock, the terminal. The service can also provide a command which enforces an expiration date. The terminal checks in with the service to determine if the account is in good standing, and is re-locked if warranted.

Description

Developer Phone Registration

Cross References to Related Applications

This application claims the benefit of US Provisional Application No. 61/296,621, filed January 20, 2010, which is hereby incorporated by reference. the

technical field

The invention relates to telephone registration technology.

Background technique

Portable terminals such as smartphones have become increasingly popular due to their ability to run third-party applications, which are usually downloaded to the terminal from a website for free or for a small fee. Such applications may include games, programs that utilize geo-location services, educational applications, etc. Terminal manufacturers encourage the development of these applications by making software development tools available to software developers. Such tools may include terminal emulators, which emulate the functionality and capabilities of a terminal, as well as tools for deploying, executing, debugging, and sharing an application prior to its commercial release. In most cases, the application is tested on the terminal itself prior to its release. However, endpoints are typically shipped such that applications can only be deployed and executed from approved (eg, trusted or authorized) sources. Developers register with the manufacturer and submit their completed applications to the manufacturer's website, where they are reviewed and approved for distribution. When a developer downloads an application to the terminal, the application is cryptographically signed with a digital signature, and the terminal verifies that the application is approved using a signature verification mechanism before allowing the application to run.

However, using such authentication mechanisms during development can make the software developer's job more difficult. Typically, the authentication mechanism is a complex and error-prone certificate-based authentication mechanism that requires the developer to manage the relationship between the endpoint and the computer on which the software development tool is running. On the other hand, if developers are granted an unlimited ability to deploy and run applications on the terminal, this makes it easier to load and run unauthorized applications, for example using application sideloading, thereby facilitating piracy. Furthermore, management challenges are presented when developers use different computers to run software development tools for different terminals. There are one computer-many endpoints management challenges, many computers-one endpoints management challenges, and many computers-many endpoints management challenges.

Contents of the invention

Techniques are provided that allow certified, registered software developers to register smartphones or other terminals with services, such as web-based services. Once an endpoint is registered, it becomes enabled to deploy, execute, debug and share unsigned applications, eg, applications that do not include cryptographic signatures. The registration to the terminal can be tied to the duration of the developer's registration.

A terminal may be a smartphone, which is a mobile phone or a cell phone with advanced capabilities and offering features similar to a personal computer (PC). Typically, a smartphone runs operating system software that provides a standardized interface and platform to application developers. Features such as e-mail, Internet access, e-book reader capabilities, on-screen or physical keyboards, and cable connectors are often provided. More generally, a terminal can be any type of terminal with network connectivity and an application platform where the distribution of applications needs to be controlled. For example, the terminal is connected via a cable or wireless link to a developer's computer, which runs software development tools. The software development tool provides a user interface that allows developers to select and register terminals.

In one embodiment, a processor-implemented method for managing a terminal with network communication capabilities is performed by one or more servers. One or more servers provide services to application developers. The method includes receiving registration information from a developer for registering as a software developer to develop an application program for a terminal. The developer may pre-register sometime before the developer is ready to deploy the application to the endpoint, or may register in conjunction with deploying the application to the endpoint. Registration information may include a developer identifier, such as developer name or email address, and developer authentication information/credentials, such as a password. One or more servers store registration information in accounts. The one or more servers send data to the developer's computer indicating that the developer has been authenticated by the one or more servers. The developer's computer provides the data to the terminal via a communications link established between the terminal and the developer's computer. This can be performed automatically, without user intervention, or in response to commands entered by the developer via a user interface at the developer's computer.

Next, the terminal initiates communication with the server. The server receives a request to unlock the terminal from client software running on the terminal, wherein the request includes the data and the terminal's identifier. The service associates the data with the developer's account and, if permitted, authorizes unlocking. The service may check to ensure that the account has not been canceled and the account's maximum allowed number of unlocked terminals has not been exceeded. Via the request and registration information, if the unlocking of the terminal is authorized, one or more servers send to the terminal a command to unlock the terminal, and in response, persist (maintain) the unlocked state in the terminal. The command may include, for example, a license file or a persistent token, such as an encrypted identifier such as a registration key, along with an expiration date. The terminal remains unlocked until the expiration date.

The unlocked state allows unsigned applications deployed by software development tools to be deployed to and executed on the endpoint. In one possible approach, in the unlocked state, a registered developer, or any other person, registered or not, may freely and repeatedly copy different compiled versions of one or more unsigned applications or Versions are deployed to endpoints, enabling applications to be deployed and run without verifying the application's digital signature. This approach greatly contributes to the speed at which the developer can work because the developer does not need to manage the relationship between the terminal and the developer or the developer's computer and the associated authentication mechanisms. Provides the best compromise between a highly secure approach that requires all applications to be authenticated before they are deployed and run, and an open access approach that allows any unsigned application to run without requiring any developer or endpoint registration. balance.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described in the specification below. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Description of drawings

Figure 1 depicts a network comprising a developer's computer, an endpoint on which an application is to be deployed, and one or more servers of a developer portal.

Figure 2 depicts a method for use with the network of Figure 1, where developers and terminals register with the developer portal's services, applications are deployed and run on the terminals, and registration terms are enforced.

FIG. 3A depicts further details of step 200 of FIG. 2, in which the developer registers with the developer portal's services.

FIG. 3B depicts an example user interface associated with step 304 of FIG. 3A in which a developer provides registration information.

FIG. 4A depicts further details of step 210 of FIG. 2 , wherein a developer registers one or more terminals with the developer portal's service to unlock the one or more terminals.

FIG. 4B depicts further details of decision step 414 of FIG. 4A , in which the service decides whether to authorize unlocking of the terminal.

4C and 4D depict example user interfaces associated with step 405 of FIG. 4A by which a developer selects one or more terminals for registration.

FIG. 4E depicts an example user interface associated with step 421 of FIG. 4A that provides a report indicating that the terminal has been unlocked.

FIG. 4F depicts an example user interface associated with step 421 of FIG. 4A that provides a report indicating all unlocked terminals associated with a developer account.

FIG. 4G depicts a process flow diagram of step 210 of FIG. 2 , wherein a developer registers one or more terminals with the service of the developer portal to unlock the one or more terminals.

FIG. 5 depicts further details of step 220 of FIG. 2, wherein the application is deployed to and runs on the unlocked terminal.

FIG. 6A depicts further details of step 230 of FIG. 2, where registration terms regarding account status are enforced.

FIG. 6B depicts further details of step 230 of FIG. 2 , where registration terms regarding expiration dates are enforced.

FIG. 6C depicts a process flow diagram of step 230 of FIG. 2 , where registration terms are enforced.

7 depicts an example block diagram of computer hardware suitable for implementing various embodiments.

Detailed ways

A terminal such as a smartphone, a service for software developers to develop applications for the terminal, and a developer's computer running software development tools/codes for the terminal are provided. Allows developers such as users/individuals to easily deploy and run applications on one or more endpoints using a streamlined registration and endpoint unlocking process. In one possible approach, once unlocked, applications can be freely and directly deployed and run. However, the developer remains responsible for these endpoints, as these endpoints are linked to the developer's registered account. Furthermore, the developer is limited in the number of terminals that can be unlocked and accessed according to the registration agreement. In addition, if the developer violates the registration agreement, the terminal can be deregistered. The terminal periodically checks the service to determine if the account is in good standing, and in response the service may provide a lock command to the terminal (if justified).

黑莓 

三星 

和 

等操作系统的手机。然而，本文中提供的概念可与具有网络连通性和应用程序平台的任何类型的终端联用，其中在鼓励第三方开发者构建应用程序的同时期望控制应用程序向终端的分发。通常，终端将可具有唯一性标识符。此类终端的其他示例包括诸如苹果 

和微软 

等便携式媒体播放器、诸如微软SURFACE^TM、平板PC等表面计算平台、诸如基于启用网络的电视等家电、诸如MICROSOFT 

等游戏设备、个人数字助理(PDA)或掌上型计算机、用于商业应用程序中的数据收集的企业数字助理(EDA)、GPS设备等。终端也可能具有标准PC操作系统，使用第三方开发模型来将应用程序部署在该操作系统上。因而，终端可以是PC。终端可以是可从零售商处购买到的大量生产的设备，或者其可以是定制的设备。Figure 1 depicts a network comprising a developer's computer, an endpoint on which an application is to be deployed, and one or more servers of a developer portal. In this example, the terminal 120 is a smartphone, the deployment of the application for which terminal is to be managed. Examples of smartphones include those running such as WINDOWS

blackberries

Samsung

and

Mobile phones with other operating systems. However, the concepts presented herein can be used with any type of terminal having network connectivity and an application platform where it is desirable to control the distribution of applications to the terminal while encouraging third-party developers to build applications. Typically, a terminal will have a unique identifier. Other examples of such terminals include

and Microsoft

Portable media players such as Microsoft SURFACE ^TM , surface computing platforms such as tablet PCs, home appliances such as web-enabled TVs, such as MICROSOFT

such as gaming devices, personal digital assistants (PDA) or palmtop computers, enterprise digital assistants (EDA) for data collection in business applications, GPS devices, etc. The terminal may also have a standard PC operating system on which the application is deployed using a third-party development model. Thus, the terminal may be a PC. The terminal may be a mass-produced device available from a retailer, or it may be a custom-made device.

A terminal 120 such as a smartphone may communicate via wireless cell phone link 104 with antenna 108 , which is in communication with cell phone facility 110 . Facility 110 may in turn communicate with one or more networks 100 (e.g., a wide area network such as the Internet and/or an intranet), as well as services that enable software developers to access terminals to develop their applications through deployment, execution, debugging, and sharing. One or more servers 160 communicate. The terminal 120 may also communicate with the one or more servers via the developer's computer 140 . To register the terminal 120, a communication link 102 is established between the terminal and a developer's computer 140 on which the software development tools run. For example, the link 102 may be a cable (tether) extending between a connector of the terminal and a connector of the developer's computer 140 . Alternatively, a wireless link may be established such as via Wi-Fi (IEEE 802.11) or Bluetooth (IEEE 802.15.1). The developer's computer communicates with one or more servers 160 via one or more networks 100 .

All actions taken by the developer's computer may also be performed by the terminal.

Terminal 120 may have several components, including client software 122 . In one approach, when the terminal establishes communication with the developer's computer 140, the client software is started. The client software is configured to provide functionality as described herein. Modern terminals often already have sufficient software and hardware resources to perform the functions described herein. In some cases, additional software may be provided to the terminal if desired. The interface 124 with the developer's computer allows the terminal to establish a connection with the developer's computer. Interfaces may include ports such as Wi-Fi circuitry or cable connectors. The interface 126 with the cellular telephone network allows the terminal to communicate voice and other data via the cellular telephone facility 110 . Interfaces may include, for example, RF transmitters and receivers. One or more processors 128 are provided to execute processor-readable code stored in volatile memory 130 such as RAM and/or non-volatile memory 132 such as ROM. Memories 130 and 132 are considered tangible computer readable storage having computer readable software embodied thereon for programming at least one processor 128 . A user interface may include a keyboard and/or a screen.

Note that in one approach, the terminal's user interface is not used as part of the application development process. Alternatively, all development occurs via the user interface of a software development tool running on the developer's computer. A software development tool may have offline capabilities (in which case it is not connected to one or more servers 160), and connected capabilities (in which case it is connected to one or more servers 160). Thus, the user interface external to the developer's computer of the terminal may be an exclusive user interface for deploying unsigned applications to the terminal. This approach makes it more difficult for unauthorized people to gain access to the terminal. Requiring the use of software development tools on a separate computer to access the terminal would deter many informal, unauthorized persons from attempting to access the terminal. Most casual users won't be able to afford to download and run software development tools.

软件开发工具包，其在VISUAL 

开发环境内起作用。SDK典型地包括供开发者编写其应用程序时测试并调制其应用程序的仿真器图像。其他示例包括先前提及的各种操作系统的SDK。开发者的计算机140可以是基本上任何类型的计算机，诸如个人计算机(PC)、桌面计算机、连接到主机的终端、一体化计算机、工作站、或膝上型计算机，包括笔记本或上网本计算机。基本上，开发者的计算机140是与终端分开的计算机，并且向开发者提供合适的资源以运行软件开发工具。开发者的计算机具有数个组件，包括软件开发工具142。在一种办法中，软件开发工具由开发者在该开发者期望使用应用程序时启动。软件开发工具被配置 成提供如本文中描述的功能，以及提供用于应用程序开发的常规工具。与终端的接口144允许开发者的计算机140与终端120通信。接口可包括例如Wi-Fi电路或缆线连接器的端口，诸如比方USB端口。Developer's computer 140 may be any type of computer on which software development tools run. An example of such software is Microsoft Windows

software development kit, which is in the VISUAL

Works within a development environment. The SDK typically includes emulator images for developers to test and tune their applications as they write them. Other examples include SDKs for the various operating systems mentioned earlier. The developer's computer 140 can be substantially any type of computer, such as a personal computer (PC), desktop computer, terminal connected to a host computer, all-in-one computer, workstation, or laptop computer, including notebook or netbook computers. Basically, the developer's computer 140 is a computer separate from the terminal, and provides the developer with suitable resources to run software development tools. The developer's computer has several components, including software development tools 142 . In one approach, a software development tool is launched by a developer when the developer desires to use an application. The software development tools are configured to provide functionality as described herein, as well as provide conventional tools for application development. The interface 144 with the terminal allows the developer's computer 140 to communicate with the terminal 120 . The interface may include eg a Wi-Fi circuit or a port of a cable connector such as eg a USB port.

The interface 146 to the service allows the developer's computer 140 to communicate with the server 160 via at least one network 100 . An interface may include, for example, a network interface card (NIC). One or more processors 148 are provided to execute processor readable code stored in volatile memory 150 such as RAM and/or non-volatile memory 152 such as hard disk or solid state memory. Memories 150 and 152 are considered tangible computer readable storage having computer readable software embodied thereon for programming at least one processor 148 . User interface 154 may include a keyboard, mouse, and/or a screen display, as discussed further below.

One or more servers 160 may be located at one or more locations. In one approach, the registration server 160 is used to store developer and terminal registration information, including a database of registered developers and terminals. The developer may establish an account maintained under a registration agreement that specifies, for example, the price the developer pays, payment information such as credit card number, the maximum number of terminals the developer may register, and an expiration date for the registration. When one or more terminals are registered, the identifiers of these terminals can be linked to the developer's account. The authentication server 164 receives and stores the developer's authentication information, such as a developer identifier and password. The developer can communicate with the authentication server directly or via the registration server. Developers can provide authentication information using single sign-on services such as WINDOWS LIVE ^™ ID, which allow users to log into multiple websites or services with one account, such as instant messaging, email, and music download sites. Another example credential authentication system is OpenID (Open ID). In one scenario, the developer is authenticated when the developer uses the developer's computer 140 to visit the website for reasons unrelated to registering with the service. When the developer is subsequently involved in the registration process, registration server 162 may access authentication server 164 to determine that the developer has been authenticated so that the developer need not provide additional authentication information.

An application server 166 for signing applications may be accessed by terminal 120 to download signed applications, which may include applications that are no longer under development and that have been approved for release by the service. Typically, such applications are classified and made available to the public. A regular user of the terminal may download the signed application from the server 166 to the terminal 120 . A signed application will only run on the terminal after its signature has been verified. Note that the same endpoint can run both signed and unsigned applications. That is, even after a terminal has been unlocked such that it runs an unsigned binary/application provided by the developer, it may retain the ability to enforce signatures on other signed applications.

The application server 168 for unsigned applications includes applications that are still in development and have not been released to the general public for approval. Often, developers try to get other developers, such as colleagues, to run and test their applications in the sharing process before their applications are released. Developers can upload applications to server 168 where they will be cataloged and made available to other registered developers on a limited basis, such as by requiring a password. Applications in this state (not yet approved for public distribution) may be signed or unsigned.

In general, the services provided may have the following features: (1) enable developers to unlock terminals through a client on the terminal that communicates with web services in an authenticated manner; (2) enable developers to manage (3) ensure that retail terminals can connect to the web service and verify whether they are locked or unlocked; (4) ensure that a given developer can only unlock a predefined number of terminals; (5) ensure that the developer portal and the web service can respond to different types of developers and ensure that the number of terminals that can be unlocked can vary depending on the type of developer; and (6) ensure that developers without the requisite account for the developer portal cannot unlock their retail terminals.

Some example scenarios implemented are as follows:

Scenario 1: Cheryl has been developing a new game for her smartphone. During the early development stages, she uses a terminal emulator to test, validate, and debug her games. She is delighted with this solution due to the speed at which she can code, build, deploy, debug, and repeat afterwards, and the fact that the terminal emulator can emulate the full range of phone behavior her game uses, such as accelerometer input. Near the end of development, she wanted to test her game on a real phone to make sure everything was working properly. She is also eager to use her games in real world situations to validate game play and overall user experience. She tethers her phone to her PC and selects the deployment command from within the software development tool. After selecting her phone from the target list, she is told she must register her phone for development, and clicks through a simple wizard. Within minutes, the phone is registered for development, the game is deployed to the phone, and she is playing the game on the phone.

Scenario 2: Timothy is developing a data snack (snack) application, for example, an application that collects small amounts of data from different websites and is ready to be deployed to its endpoints. He tethers the terminal to the PC and selects the deploy command from within the software development tool. After selecting his endpoint from the target list, he is told that he must register his endpoint for development, and clicks through a simple wizard. As he progressed through the wizard, he was told that he was not fully registered as an end developer. The web browser launches to the developer portal where he completes his registration. He then returns to the Developer Terminal Wizard, where he confirms that he is now properly registered. Within minutes, the endpoint is registered for development, his application is deployed to the endpoint, and he runs the application.

Scenario 3: Kathy is building a music video application ready to be deployed to her endpoint. She tethers her terminal to her PC and selects the deployment command from within the software development tool. She previously registered her terminal, so when she selects a terminal from the target list, the application is deployed immediately and within a minute, she is able to interact with her application on the terminal.

Scenario 4: Kevin is building a mapping application ready to be deployed to his endpoint. He establishes a wireless link between the terminal and the PC, and selects a deployment command from within the software development tool. With his terminal selected from the target list, he was informed that his developer registration had expired. His web browser launches to the developer portal where he updates his registration. He then returns to the Developer Terminal Wizard, where he confirms that he is now properly registered. Within minutes, his endpoint is registered for development, his application is deployed to the endpoint, and he runs the application.

In one approach, services may deploy HTTP-based application programming interfaces (APIs) that allow terminals to perform actions such as requesting their status (locked or unlocked), setting their status (locked or unlocked), and using Its unique terminal identifier (TerminalID (terminal ID)) and data indicating that the developer has been authenticated are authenticated. The service also enforces a maximum number of allowed endpoints per developer, which can be adjusted on a per-developer basis. The service may also provide an administrator console that allows administrators to adjust the number of allowed terminals that will be unlocked for a given account.

The following sample methods are available:

(1) Unregistered terminal command service issues a lock command to the terminal. Locking a terminal removes it from the list of unlocked terminals. Authentication is required. Inputs include TerminalID and Authenticated User Portable Unique Identifier (PUID). Output includes pass or fail status.

(2) Register the terminal instruction service to issue an unlock command to the terminal. Unlocking a terminal adds it to the list of "unlocked" terminals for a specific developer account. An authenticated user session containing the authenticated user's PUID is required. Inputs include Terminal ID, Authenticated, Nickname, and PUID. Output includes pass or fail status and the number of days until expiration, or expiration date.

(3) Get Device Status returns the status (locked or unlocked) of a specific terminal. Authentication is not required. The input includes the terminal ID. Outputs include unlocked, locked, or not found status. If unlocked, the service will send the expiration interval (time before expiration) to the terminal. If locked, the service returns zero.

From a logical standpoint, some basic requirements can include the following: (1) Any developer who unlocks an endpoint via the API must have a valid account status - meaning at a minimum, they must pay any required fees and must be granted Access the portal. (2) The API enforces endpoint counting by account type. Example account types include partner organization accounts (where the partner organization has an established work agreement with the service provider), non-partner organization accounts (where the non-partner organization has no work agreement with the service provider), and individual accounts. For organizational accounts, the default number of allowed endpoints is usually greater than for individual accounts. The default allowed endpoint data should be configurable on a per-account basis. (3) If the developer exceeds the number of allowed terminals, an exception is thrown and the developer is asked (via the terminal client) to remove a terminal from the developer portal's list. (4) Terminal unlocking should enforce an expiration timeline for unlocking the terminal. The default expiration of an unlocked terminal is 12 months and is tied to the expiration of the developer account. (5) An expired registration should return the terminal to the locked state automatically, just as a re-registration should extend the expiration date and keep the terminal unlocked.

The following is an enumeration of some basic error codes that the API can return: Error 901——Account is not active, Error 902——Account not found, Error 903——The terminal technology exceeds, Error 904——Unable to unlock the terminal (generic), Error 905— - Failed to lock terminal (generic), and error 906 - Terminal ID not found.

The following represent sample APIs that the service can use.

(1) Get device status

Path: http://api.developer.windowsphone.com/tools/02/2010/terminals/GetStatus? terminalId: Guid

Method: get

Description: Get the status of the terminal, whether it is locked, unlocked or not found.

Project: Terminal State Enumeration

UrlParameters (Url parameters)

terminalId: String (Globally Unique Identifier or GUID) indicating the terminal to look for

Sample response:

(2) Lock terminal

Path: http://api.developer.windowsphone.com/tools/02/2010/terminals/LockTerminal? terminalId:Guid}

Method: delivery

Description: The command service issues a lock command to the terminal.

Project: Terminal State Enumeration

UrlParameters (Url parameters)

terminalId: string (GUID), indicating the terminal to find and lock

liveIDTicket (survival ID ticket): a ticket containing developer information (in the header)

Sample response:

Note that a GET request only fetches data from a web server based on the URL value and a set of HTTP headers. There is no extra data about the GET request; everything is specified in the URL and headers. In contrast, a post request sends additional data (specified after the URL), headers, and a blank line to indicate the end of the headers to the web server.

Figure 2 depicts a method for use with the network of Figure 1, where developers and terminals register with the developer portal's services, applications are deployed and run on the terminals, and registration terms are enforced. In step 200, the developer registers with the service according to the registration agreement. Further details of step 200 are provided in connection with Figures 3A and 3B.

At step 210, the developer registers one or more terminals with the service to unlock the one or more terminals. Further details of step 210 are provided in connection with Figures 4A-4g. In step 220, the developer deploys and runs the application program on the one or more terminals. Further details of step 220 are provided in connection with FIG. 5 . At step 230, the terms of the registration agreement are enforced, eg, during a period of time during which one or more terminals are registered. Further details of step 230 are provided in connection with Figures 6A-6C.

FIG. 3A depicts further details of step 200 of FIG. 2, in which the developer registers with the developer portal's services. In one scenario, a developer begins pre-registration at step 300 . Generally, this happens when the developer registers himself or herself with the service at some point before registering the endpoint with the service. At step 302, the developer accesses the service's web site to register, eg, using a conventional web browser. At step 304, the developer provides registration information via the web site. See Figure 3B for further details. At step 306, the service stores the information, for example, on one or more servers. At step 308, the service sends data to the developer's computer indicating that the developer has been authenticated. This data may include, for example, service tickets or other encrypted cookies with tokens or instantiated key-value pairs. At step 310, the data is stored on the developer's computer.

In a second registration scenario, the developer initiates registration via a software development tool on the developer's computer, such as in conjunction with a registration terminal (step 312). In step 314, the developer selects a terminal to register via the user interface. At step 316, the developer is redirected to the service's web site to register and the remaining steps 304-310 proceed as previously discussed.

FIG. 3B depicts an example user interface associated with step 304 of FIG. 3A, where a developer registers with the developer portal's services. An example user interface or screen display 320 is for "Developer Registration." It includes a section 322 for developer information, where the developer clicks through to a form to enter, for example, a developer identifier, developer name and contact information. Section 324 is for account setup, where the developer clicks into a form to enter, for example, the number of terminals to register, expiration dates, and licenses. Different permissions can optionally be used to respectively grant access to different features. For example, different licenses may allow the terminal to run debugging applications and development related processes such as profilers, which may be part of software development tools. In another example, one license may be suitable for student software developers and implement only basic application development features for the terminal, while another license may be suitable for professional software developers and implement basic or advanced application development features for the terminal .

Section 326 is for payment information, where the developer clicks through to a form to enter, for example, a credit card number, etc. Section 328 is for authentication, where the developer clicks through to a form to enter authentication information, such as a developer ID (if different from that used in developer information 322), and a password. For example, with a WINDOWS LIVE ^(TM) ID, the developer provides an email address and password. The developer authentication information does not need to be associated with the developer's computer, so that the terminal is not dependent on running only through the developer's computer. Button 330 allows the developer to cancel the current input, while button 332 allows the developer to save the current input.

FIG. 4A depicts further details of step 210 of FIG. 2, wherein a developer registers one or more terminals with the developer portal's service to unlock the one or more terminals. At step 400, a communication link between the terminal and the developer's computer is established. As mentioned above, this may include connecting cables between the two devices. At step 402, client software is started at the terminal in response to detecting the communication link. Starting the client software only when the communication link is established minimizes the performance impact on additional applications/services running on the terminal.

使用API GetDeviceUniqueID()(获得设备唯一性ID())。在步骤408，请求可以是使用终端处的API的标准web服务调用。例如，可使用HTTP调用，其中头部携带指示开发者已被认证的数据。At step 404, the client software waits and listens for inbound messages from the developer's computer. In step 405, the developer selects a terminal via the user interface of the software development tool. In response, at step 406, the developer's computer sends data to the terminal indicating that the developer has been authenticated. This could be, for example, the data mentioned in steps 308 and 310 of Figure 3A. In response, at step 408, the terminal sends a request to the service to unlock itself, wherein the request includes the data received from the developer's computer and the terminal identifier. Identifiers may include, for example, hardware-specific certificates, terminal serial numbers, or other unique terminal identifiers. An example is an International Mobile Equipment Identity (IMEI) number. Note that some terminal identifications such as the IMEI number are accessible by the developer via the terminal's user interface as well as by the client software at the terminal. The identifier should be unique to the terminal and should not change despite reset or reformatting of the terminal. The terminal may have an API directly bound to the hardware to allow client software to access the identifier. For this purpose, WINDOWS

Use the API GetDeviceUniqueID() (Get Device Unique ID()). At step 408, the request may be a standard web service call using the API at the terminal. For example, an HTTP call may be used where a header carries data indicating that the developer has been authenticated.

The terminal may communicate with one or more servers of the service in a pass-through manner via the developer's computer (step 412), or via another link such as a cell phone channel (step 410, See Figure 1). For example, with respect to step 412, MICROSOFT Synchronization is performed using desktop pass-through (DTPT) technology. DTPT enables a terminal to transparently access an external network such as the Internet through a developer's computer to which the terminal is connected. Another way is to connect the terminal to the service via USB using an emulated serial port.

等数字版权管理(DRM)方案来提供示例许可证。许可证的特性确保其未被篡改以及来自权威性场所。许可证文件可包括证书文件。In decision step 414, the service determines whether unlocking of the terminal is authorized. Further details are provided in Figure 4B. If at decision step 414 the unlocking is authorized, then at step 416 the service sends a command to the terminal with unlocking data (such as a license file or a persistent token like a registration key) and an expiration date. Registration status (unlocked or locked) can be maintained as a boolean value or secured by a license or certificate. The terminal determines that it is unlocked by detecting the presence of a persistent token or license file. can use such as Microsoft

Example licenses are provided for digital rights management (DRM) schemes such as The nature of the license ensures that it has not been tampered with and is from an authoritative place. License files may include certificate files.

Expiration data may be represented by, for example, a time period in which unlocked status is authorized to be persistent, such as one year, or an expiration date. Alternatively, the terminal can be configured to enforce a default expiration date. Note that the commands may be provided in one or more messages from the service to the terminal. For example, one message may include unlock data, while another message may include an expiration date. The command may also include the developer's identifier for tracking purposes. The developer's identifier can be stored on the terminal.

Persisting in an unlocked state may include maintaining or storing unlock data on the terminal. The logic flow at the client software can implement an alternate behavior by recognizing the unlock state. For example, unlocked status can be identified by validating a license. A locked state may indicate that only signed applications downloaded from the service may run on the terminal, while an unlocked state behavior may indicate that unsigned applications downloaded from software development tools or other sources may also run on the terminal.

In general, by using credentialing material, such as a hash of some known server value (e.g., an identifier associated with the server), it can be verified that the unlocked state of the terminal has not been tampered with.

The unlock data provided at step 416 may provide control of additional unlock constraints in the same manner as the unlock duration/expiration is controlled in addition to unlock status. For example, unlock data can: (a) limit the number of applications that can be installed from the service onto an unlocked terminal; (b) set controls on the expiration of installed applications; (c) limit the launch of several applications times, and so on.

In case (a), if the limit on the number of installed applications has been reached, the developer will be prohibited from installing additional applications on the terminal. A message notifying the developer of the restriction may be provided on the developer's computer. The developer may be notified of the option to delete previously installed applications so that new applications can be installed without exceeding the limit, or to access the service to purchase additional rights to install another application.

In case (b), the time at which the authorization to run the application expires may be set. Different installed applications may have different expiration times. Application-specific expiration dates may be enforced in a manner similar to the manner in which expiration dates for terminal registrations are enforced, for example, as discussed below in connection with FIGS. 6A and 6B .

In case (c), if the limit of the number of times the application can be launched has been reached, the developer will be prohibited from launching the application again on the terminal. A message notifying the developer of the restriction may be provided on the developer's computer. The developer may be notified of the option to access the service to purchase additional rights to launch the application. For example, this limit can be enforced on a per-application basis.

In step 418, the terminal stores the unlock data and the expiration date. At step 419, the terminal unlocks itself, such as by calling an API using the unlock data. An example call has the following format: SetDeveloperUnlockState(DEVELOPERUNLOCK_STATE_UNLOCKED)(set developer unlock state(developerunlock_state_unlocked)).

SILVERLIGHT^TM应用程序的zip(压缩)文件。微 

SILVERLIGHT^TM是web应用程序框架，其提供与 

平台中的那些相类似的功能，将多媒体、图形、动画和交互性整合到单个运行时环境中。通过此机制部署到终端的所有二进制文件可在初始化时调用GetDeveloperUnlockState(获得开发者解锁状态)，并验证其返回 DEVELOPERUNLOCK_STATE_UNLOCKED以验证终端被解锁。如果终端未被解锁，则这些二进制应终止。在所有二进制已被复制到终端并被安装之后，开发者的计算机上的用户界面可向开发者通知终端可用(步骤421)并显示终端的标识符(参见图4F)。In step 419, if the unlocking is successful, the binary file (binary) from the software development tool may be copied from the developer's computer to the terminal (step 420). In an example implementation, each binary file can be packaged as a XAP file and deployed to a package manager for installation. XAP is a micro-

The zip (compressed) file of the SILVERLIGHT ^TM application. micro

SILVERLIGHT ^TM is a web application framework that provides and

Similar capabilities to those in the platform, integrating multimedia, graphics, animation, and interactivity into a single runtime environment. All binaries deployed to the terminal through this mechanism can call GetDeveloperUnlockState (to obtain the developer unlock state) at initialization time, and verify that it returns DEVELOPERUNLOCK_STATE_UNLOCKED to verify that the terminal is unlocked. These binaries should terminate if the terminal is not unlocked. After all binaries have been copied to the terminal and installed, the user interface on the developer's computer can notify the developer that the terminal is available (step 421) and display the terminal's identifier (see FIG. 4F).

If at decision step 414 the unlocking is not authorized, then at step 422 the service optionally sends an error message to the terminal, and at step 424 the terminal may optionally report a corresponding error message to the developer's computer via a software development tool.

FIG. 4B depicts further details of decision step 414 of FIG. 4A in which a determination is made as to whether unlocking of the terminal is authorized. For example, at step 426, the service identifies the developer's account based on the developer authentication information provided by the terminal. This developer authentication information may be data provided to the developer's computer that indicates that the developer has been authenticated by one or more servers of the service. In step 428, the service verifies the developer authentication information provided by the terminal with the developer authentication information previously associated with the account to ensure that there is a match. NOTE: During the initial communication from the terminal to the service, the terminal identifier may not be associated with the developer account. After the terminal is registered, the terminal identifier is associated with the developer account so that subsequent requests from the terminal can be associated with the developer account based on the identified terminal. The terminal may (but need not) provide developer authentication information in subsequent requests.

Decision step 430 determines whether the registered account is still valid. If the terms of the registry agreement have been violated, such as non-payment or other violations such as fraud or use of malware, the account may be invalid. These other actions may be known to administrators with authority to disable accounts. Decision step 432 determines whether a registration slot is available. A slot is available if the maximum allowed number of terminals to be registered for the account has not been exceeded. Decision step 434 determines whether the terminal is already registered. For example, the terminal identifier may be in a list of terminal identifiers registered to the account. If decision steps 430 , 432 , and 434 are true, then at step 436 unlocking of the terminal is authorized. Otherwise, unlocking of the terminal is not authorized at step 438 .

智能手机的示例型号名称。可选择按钮452以取消过程，而可选择按钮454以使用本文中所描述的技术来注册终端。4C and 4D depict example user interfaces associated with step 405 of FIG. 4A by which a developer selects one or more terminals for registration. In FIG. 4C, an example user interface or screen display 440 is used to "Add Terminal." It includes a section 442 where the developer can select the type of terminal, such as "Windows Phone", "Xbox" or "Zune". In this example, "Windows Phone" is selected by the developer through appropriate input, eg, using a mouse. Button 444 can be selected to cancel the process, while button 446 can be selected to find the selected type of terminal. When button 446 is selected, the software development tool uses an auto-detection technique to automatically detect any terminal that has a communication link with the developer's computer and is of the selected type. In FIG. 4D , an example user interface or screen display 450 indicates that a terminal of the selected type has been found, and provides an identification of the terminal, such as "HTC Touch Pro2", which is

An example model name for a smartphone. Button 452 may be selected to cancel the process, while button 454 may be selected to register the terminal using the techniques described herein.

FIG. 4E depicts an example user interface associated with step 421 of FIG. 4A that provides a report indicating that the terminal has been unlocked. An example user interface or screen display 460 indicates that the selected terminal has been successfully registered and provides an identification of the terminal. Button 462 may be selected to proceed to other portions of the software development tool that allow preparation, deployment, execution, debugging or sharing of applications.

FIG. 4F depicts an example user interface associated with step 420 of FIG. 4A that provides a report indicating all unlocked terminals associated with a developer account. A user interface may be provided via the service's web site and allow registered developers to view and remove/logout currently unlocked terminals to ensure that the online list of registered terminals is kept in sync with those actually registered. The user interface also allows the developer to manage a limited number of terminals, determine the number of allowed registered terminals and counts of locked and unlocked terminals, determine the default allowed number of unlocked terminals per account type. In one approach, the developer needs to have an account before accessing the user interface.

The example user interface or screen display 470 includes an "Account Information" section containing various selections. User Profile can be selected to view and update details such as developer name and contact information. Optionally select Commercial Details to view information such as the terms of the registration agreement. Optionally select "Payment Information" to view details such as the credit card number on file. Here, "Terminal Manager" is selected, resulting in display area 474 depicting "My Unlocked Terminal". This area provides an overview of all endpoints that have been registered to the developer. Area 474 indicates the current number of unlocked terminals, for example 3, and the maximum allowable number of unlocked terminals, for example 5. For each of the three terminals, provide the terminal name, terminal identifier, unlock expiration date, and "remove" action. The "Remove" link can be selected to unregister the corresponding terminal. In one approach, upon selection of button 478, the developer's computer or service sends a logout command to the terminal, and in response, the terminal sends a request to the service to logout of the terminal and receives a corresponding command from the service to logout. In this way, the service can manage the terminal. The request may include data authenticating the developer, similar to the request for registration discussed previously. Button 476 may be selected to cancel the current user interface selection.

Fig. 4g depicts a process flow diagram of step 210 of Fig. 2, wherein a developer registers one or more terminals with the service of the developer portal to unlock the one or more terminals. In process 480, the developer's computer sends a registration request to the terminal to request the terminal to register itself. In process 481, the terminal accesses its identifier using the call GetDeviceUniqueID. At process 482, the terminal sends authentication data to the service. In process 483, the service determines whether the developer account is current and valid. If the account is not current and valid, error handling 484 occurs. Example error codes are discussed above with reference to FIG. 1 . In process 485, the service determines whether there are registration slots available, eg, whether the maximum number of terminals has already been registered to the account. If there are no registration slots available, then error handling 486 occurs. If error handling 484 or 486 occurs, then error handling 487 occurs from the terminal to the developer's computer.

At process 488, the service determines whether the requesting terminal is already registered to an account. In process 489, the service performs a registration. The procedure provides registration results to the terminal, such as a command to unlock the terminal. Error handling occurs 491 from the terminal to the developer's computer if necessary, for example, if the terminal is already registered. At process 492, the terminal unlocks itself. At process 493, the result of the registration—eg, an indication that the terminal has been unlocked—is provided from the terminal to the developer's computer.

FIG. 5 depicts further details of step 220 of FIG. 2, wherein the application is deployed to and runs on the unlocked terminal. At step 500, a developer develops an application using a software development tool on the developer's computer, the software development tool including a terminal emulator. In step 502, the developer uses a software development tool to deploy and run the unsigned application on the terminal. At step 504, the client software on the terminal receives and stores the unsigned application without verifying its authenticity.

As mentioned above, once a terminal is unlocked, it can run unsigned applications, thereby facilitating the work of developers. Typically, a developer will develop several compiled versions of an application throughout the day, which are each deployed and run. Developers can deploy individual builds independently of the service. This is beneficial to other approaches where developers use a certificate-based system to authorize and sign individual compiled versions of an application, where the certificate is unique to the developer. Such approaches install and store the certificate on the terminal and require several setup steps.

In contrast, the unlocked state allows an unsigned application developed by another instance of a software development tool, eg, on another developer's computer, to be directly deployed to and executed on the terminal. Thus, a developer can connect a terminal to another developer's computer running another instance of a software development tool, and deploy a separate application/compiled version of an application to the same terminal. Thus, the unlocked state of the terminal is persistent regardless of the developer's computer used to register it, so that the unlocked state allows the application to be downloaded from different instances of the software development tool running on different developers' computers. Deploy to a terminal and execute on that terminal. Furthermore, the unlocked state of the terminal persists regardless of the developer and the developer's account, such that the unlocked state allows applications to be deployed to and executed on the terminal from different users of the software development tool.

Additionally, unsigned applications can be deployed to any registered endpoint. With other methods, the developer must know ahead of time which terminals the application will run on and must keep track of that information, and if the developer tries to run the application on another terminal, or if another developer tries to run the application, Then it will not run because the authorization to run is tied to the developer or the developer's computer.

The above-mentioned advantages provide great flexibility and efficiency in the development process involving one or more developers. The certificate equivalence level security provides a simple "keep open" level for developers, as if the terminal was shipped unlocked. Furthermore, although applications can be loaded without interacting with the service or other centralized manager, the service maintains control over the terminals as they can be unregistered (deregistered) as they periodically register. For example, a developer who is known to have violated a registration agreement (such as by distributing code-cracking software) may have his or her account cancelled, so that terminals registered to the developer are deregistered when they register. Registration may occur relatively frequently, such as once every two weeks, so that the period of unauthorized use is not as long. In another possible scenario, a developer's registered terminal may be lost or stolen, in which case the developer may request the service to deregister the terminal the next time the terminal registers, so that the developer may register another Terminals to replace lost or stolen terminals without exceeding the maximum number of terminals allowed under the registration agreement. Furthermore, the terminal itself can be associated with a particular developer by its identifier, so that accessing the developer identifier in the phone can make the developer liable for giving the terminal to another person in violation of the registration agreement.

At step 506, the developer performs debugging of the application program using a software development tool. Optionally, at step 508, the developer can share the application with other registered developers and their registered endpoints so that they can test the application and provide feedback. One possible way of doing this involves developers uploading unsigned applications to the service. At step 510, the service stores and catalogs the application. At step 512, another registered developer downloads the unsigned application from the service to his or her computer so that it can be deployed to any registered endpoint.

Specifically, in order to share an application, the developer may pre-register with the service a terminal that will download the shared unsigned application. This registration process may involve the developer authenticating himself or herself to the developer portal, eg, by logging in using their authentication information. The developer then provides a non-spoofable device-specific identifier, such as an IMEI number, or a hardware-based hash returned by an API such as GetDeviceUniqueID(). Sharing involves receiving and provisioning a terminal-specific license, which may be implemented as a terminal-specific certificate at the terminal. The license can be used by various processes as verification that the terminal has been unlocked and authorized for sharing.

FIG. 6A depicts further details of step 230 of FIG. 2, where registration terms regarding account status are enforced. As mentioned above, while providing developers with great flexibility and ease of use, services still maintain a certain degree of control over the deployment of applications to endpoints. In one possible approach, the terminal is configured to periodically communicate its identifier to the service at step 600 in order to verify the status of the terminal during the registration process. Registration may occur based on a non-deterministic schedule, for example at randomized times, when a terminal is connected to the network, such as once every few days. For example, a smartphone may register via a cell phone link or via a Wi-Fi or Bluetooth connection. At step 602, the service accesses registration information based on the identifier to identify a corresponding account and determine the status of the account. For example, the status can be valid or invalid/cancelled. The terminal identifiers are linked in the database to corresponding developer accounts and associated account status information. In decision step 604, if the account is valid, then in step 608, the service sends a command to the terminal to continue the persistent unlocked state. If the account is invalid, then at step 606, the service sends a command to the terminal to set and maintain the locked state.

For example, the API SetDeveloperUnlockState(DEVELOPERUNLOCK_STATE_LOCKED) (Set Developer Unlock State (DEVELOPERUNLOCK_STATE_LOCKED)) may be called to re-lock the terminal when the terminal receives the command. In one approach, binaries from software development tools and any unsigned applications that have been installed to the terminal may remain while the locked state persists. In this case, the developer's continuity is maintained if the terminal becomes unlocked again. Alternatively, binaries and/or any unsigned applications may be deleted when the locked state is initiated. Note that the terminal can also be locked based on a developer command—eg, via the "remove" action in the user interface of FIG. 4F. A developer may desire to deregister a terminal when the terminal is no longer required for application development.

FIG. 6B depicts further details of step 230 of FIG. 2 , in which registration terms regarding expiration dates are enforced. At step 610, the terminal stores an expiration date based on a command from the service, eg when the terminal is unlocked for the first time. At decision step 612, when the expiration date is reached (and/or some time before and/or after the expiration date), the terminal communicates its identifier to the service to determine at step 614 whether the terminal's registration has been renewed . The service may pre-contact the developer, such as via an email message, to notify the developer to renew the service, such as by visiting the service's web site.

Note that a terminal may also have its maintenance expiration date aligned with the server's maintenance expiration date by registering with the service from time to time prior to the terminal's maintenance expiration date and by checking in to the service under the terminal's maintenance expiration date. consistent. If there is a discrepancy, the terminal may change its expiry date to correspond to the expiry date maintained by the service.

At step 616, the service accesses the registration information based on the identifier to determine the status of the corresponding account. At decision 618, if the registration has been renewed, then at step 622 the service sends a command to the terminal to continue the persistent unlocked state. If the registration has not been renewed, then at step 620 the service optionally sends a command to the terminal to set and persist the locked state. The terminal may also return to the locked state once it detects that the expiration date has passed.

As mentioned above in connection with Figure 4A, the unlock data provided to the terminal may set the time at which the authorization to run the application expires. Furthermore, different installed applications may have different expiration times. Enforcement of application-specific expiration dates may continue based on the discussion above with respect to Figures 6A and 6B.

In the example of FIG. 6A, step 600 may be modified to provide for the terminal to communicate the identifier of the application to the service. Step 602 may be modified to provide for a service to determine the status of one or more applications that have been authorized to the terminal, for example by using the identifiers of the applications. Step 604 may be modified to provide for the service to determine whether the application is valid, for example, if its expiration date has not been reached, then it is valid. The service may compare the application's identifier against a stored expiration date. If the application's authorization has expired, but the account is still valid, step 608 may be modified to provide for the service to send a command to the terminal to continue the locked state of the particular application. Thus, an authorized application may be considered to have an unlocked state similar to the terminal's unlocked state, and an application that is no longer authorized may be considered to have a locked state similar to the terminal's locked state.

In the example of FIG. 6B, step 610 may be modified to specify an expiration date for the terminal to store one or more applications that have been authorized for the terminal. Step 612 can be modified to stipulate that the terminal determines whether the expiration date of the application has been reached. The terminal may compare the application's identifier against a stored expiration date. If the application has expired, step 614 may be modified to provide for the terminal to determine from the service whether the authorization to the application has been renewed. This can be done even if the terminal's expiration date has not yet been reached. Step 616 may be modified to specify that the service access the application's registration information to determine whether the application has been renewed. The service may compare the application's identifier against data indicating whether the application has been renewed. Step 618 may be modified to specify that the service determines the state of the application. At decision 618, if the application's registration has been renewed, then at step 622 the service may send a command to the terminal to continue to persist the unlocked state of the application. The terminal can also cause the application to go back into a locked state once it detects that the application's expiration date has passed. Thus, an application can be considered to have a registration similar to that of a terminal. Different applications can be considered to have different registrations.

Note that modifications to the process of FIGS. 6A and 6B as discussed above may be used in addition to and in place of the use of the process in FIGS. 6A and 6B to enforce registration terms on terminals. The use of the process for enforcing registration terms on terminals in Figures 6A and 6B may be performed at a different time than the use of the process in Figures 6A and 6B for enforcing registration terms for applications. Similarly, the processes of Figures 6A and 6B may be performed at different times for different applications of a terminal or terminals.

FIG. 6C depicts a process flow diagram of step 230 of FIG. 2 , where registration terms are enforced. At process 630, the terminal determines whether its registration has expired. At process 632, the terminal communicates with the service to determine whether the terminal is registered, eg, whether its registration has lapsed due to non-renewal or a violation of the registration agreement.

7 depicts an example block diagram of computer hardware suitable for implementing various embodiments. Computer hardware may represent, for example, a developer's computer, terminal, and/or server as discussed herein. An exemplary system for implementing various embodiments includes a general purpose computing device 710 . Components of the computing device 710 may include a processing unit 720 , a system memory 730 , and a system bus 721 coupling various system components including the system memory to the processing unit 720 . The system bus 721 can be, for example, a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.

Computing device 710 may include various tangible or non-transitory computer or processor readable media. Computer readable media can be any available media that can be accessed by computing device 710 and includes both volatile and nonvolatile media, removable and non-removable media. Computer readable media may include computer storage media, such as volatile and nonvolatile, removable and Non-removable media. Computer storage media including, but not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic tape cartridges, tapes, magnetic disk storage or other magnetic storage devices, or Any other medium that can be used to store the desired information and that can be accessed by computing device 710 . Combinations of any of the above are also included within the scope of computer readable media.

System memory 730 includes computer storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) 731 and random access memory (RAM) 732 . Basic input/output system 733 (BIOS), which contains the basic routines that facilitate the transfer of information between elements in computing device 710, such as at startup, is typically stored in ROM 731. RAM 732 typically contains data and/or program modules that processing unit 720 can immediately access and/or is currently operating on. For example, operating system 734, application programs 735, other program modules 736, and program data 737 may be provided.

Computer system 710 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 7 illustrates non-removable, non-volatile memory 740, such as solid-state memory, and a memory card (e.g., SD card) interfacing/reading from or to a removable, non-volatile memory card 752. Extractor 750. Other removable/non-removable, volatile/nonvolatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, flash memory cards, digital versatile disks, digital video tapes, solid state RAM, solid state ROM, etc. .

Computer storage media provide storage of computer readable instructions, data structures, program modules, and other data for the computing device 710 . For example, non-removable, non-volatile memory 740 is shown as storing operating system 744 , application programs 745 , other program modules 746 , and program data 747 . These components may or may not be the same as operating system 734 , application programs 735 , other program modules 736 , and program data 737 in system memory 730 . Operating system 744, application programs 745, other program modules 746 and program data 747 are here labeled differently to illustrate at least that they are different copies. A developer may enter commands and information into computing device 710 through input devices such as keyboard/touch screen 762 and microphone 761 . Other input devices (not shown) may include joysticks, game pads, satellite dishes, scanners, and the like. These and other input devices are typically connected to the processing unit 720 by a developer input interface 760 coupled to the system bus, but may also be connected by other interfaces and bus structures, such as parallel ports, game ports or universal serial bus (USB). Display/monitor 791 is also connected to system bus 721 via an interface, such as video interface 790 . Other peripheral output devices such as audio output 797 may be connected through output peripheral interface 795 .

Computing device 710 may operate in a networked environment using logical connections to one or more remote computing devices, such as remote computing device 780 . Remote computing device 780 may be another mobile device, personal computer, server, router, network PC, peer-to-peer device, or other common network node, and generally includes many or all of the elements described above with respect to computer 710 . Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a networked environment, computing device 710 connects to another network through network interface or adapter 770 . In a networked environment, program modules depicted with respect to computing device 710, or portions thereof, may be stored in the remote memory storage device. For example, remote application 785 may reside on memory device 781 . The network connections shown are exemplary and other means of establishing a communications link between the computing devices may be used.

The foregoing detailed description of the technology described herein has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. The above-described embodiments were chosen to best explain the principles of the technology and its practical application, to thereby enable others skilled in the art to best utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated . It is intended that the scope of the technology be defined by the appended claims.

Claims (15)

1. A method implemented by a processor for managing a terminal having network communication capability executed by one or more servers, comprising: receiving registration information for registering as a software developer to develop an application program for the terminal (120) from the developer via the developer's computer (140), the registration information including a developer identifier and a developer Certification Information; storing said registration information; sending data indicating that the developer has been authenticated by the one or more servers (160) to the developer's computer, the developer's computer via an a communication link (102) for providing said data to said terminal; receiving a request to unlock the terminal from client software (122) running on the terminal, the request including the data and an identifier of the terminal; and Based on the request and the registration information, determining whether unlocking of the terminal is authorized, and if the unlocking of the terminal is authorized, sending a command to the terminal to unlock the terminal in response , persisting in the terminal an unlocked state that permits deployment to the terminal of one or more unsigned applications developed by an instance of a software development tool running on the developer's computer and Execute on the terminal. 2. The method implemented by the processor according to claim 1, characterized in that: said registration information indicates which of one or more of a plurality of available licenses said developer has registered for; the order indicates the one or more licenses that the developer has registered; and The one or more permissions are enforced by the terminal in response to the command. 3. The method implemented by the processor according to claim 1 or 2, characterized in that: the registration information includes a specification regarding a maximum allowable number of unlocked terminals that can be registered to the developer; and The unlocking of the terminal is authorized on the basis that the unlocking does not violate the regulations. 4. The processor-implemented method according to any one of claims 1 to 3, wherein the command identifies a period during which the unlocked state lasts, the method further comprising: receiving said identifier of said terminal from said terminal at the end of said period; identifying the developer's account based on the identifier; determine whether said account of said developer has been renewed; and In response to the determination, sending a command to the terminal to continue the unlocked state if the account has been renewed, or sending a command to the terminal to continue the unlocked state if the account has not been renewed. command to lock the state. 5. The processor-implemented method according to any one of claims 1 to 4, wherein the command identifies a period during which the unlocked state continues, the method further comprising: receiving the identifier of the terminal from the terminal before the end of the period; identifying the developer's account based on the identifier; determine whether said account of said developer has been cancelled; and In response to the determination, sending to the terminal a command to continue the unlocked state if the account has not been cancelled, or sending a command to the terminal to continue the locked state if the account has been cancelled. The command. 6. A processor-implemented method according to any one of claims 1 to 5, characterized in that: The registration information includes a specification regarding a maximum allowable number of applications that can run on an unlocked terminal registered to the developer. 7. A processor-implemented method according to any one of claims 1 to 6, characterized in that: The registration information includes a specification regarding a maximum number of times an application can be launched on an unlocked terminal registered with the developer. 8. A processor-implemented method according to any one of claims 1 to 7, characterized in that: The registration information includes specifications regarding application-specific expiration dates for applications registered on the developer's unlocked terminal. 9. A terminal with network communication capability, comprising: at least one tangible non-volatile storage medium (740, 750) storing client software (122, 128); and at least one processor (720) that executes the client software to: (a) receive communications from an instance of a software development tool of a developer's computer (140) via a wired or wireless link (102), the communications comprising data indicating that a developer of said instance of said software development tool has been authenticated by one or more servers (160), (b) in response to said communication, sending to said one or more servers a request for unlocking said terminal a request comprising the data and an identifier of the terminal, and (c) receiving back from the one or more servers a command to unlock the terminal, in response, continuing in the terminal An unlocked state that permits deployment to and execution on the terminal of one or more unsigned applications developed by the instance of the software development tool. 10. The terminal according to claim 9, characterized in that: The command includes a license file or a persistent token that is stored to persist the unlocked state. 11. The terminal according to claim 9 or 10, characterized in that: The unlocked state allows one or more unsigned applications developed by another instance of the software development tool to be deployed to and executed on the terminal. 12. The terminal according to any one of claims 9 to 11, characterized in that: Persisting the unlocked state independently of the developer's computer such that the unlocked state allows one or more unsigned applications from different instances of the software development tool running on different developers' computers to Deploy to and execute on the terminal. 13. The terminal according to any one of claims 9 to 12, characterized in that: Persisting the unlocked state independently of the developer such that the unlocked state allows future deployment of one or more unsigned applications of a different developer of the software development tool to the terminal and on the terminal to execute. 14. The terminal according to any one of claims 9 to 13, wherein the command identifies a period during which the unlocked state continues, and the method further comprises: sending said identifier of said terminal to said one or more servers at the end of said period, said one or more servers identifying said developer's account based on said identifier of said terminal, and determining whether the account in question has been renewed; and Instructions for continuing the unlocked state are received when the account has been renewed, or instructions are received for continuing the locked state when the account has not been renewed. 15. The terminal according to any one of claims 9 to 14, wherein the command identifies a period during which the unlocked state continues, and the method further comprises: sending said identifier of said terminal to said one or more servers prior to the end of said period, said one or more servers identifying said developer's account based on said identifier of said terminal, and determining whether the account in question has been cancelled; and An instruction is received to continue the unlocked state when the account has not been cancelled, or an instruction to continue the locked state is received when the account has been cancelled.

Images