Patent Application
20080005026
The subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject matter. It may be evident, however, that subject matter embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the embodiments.
As used in this application, the term “component” is intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a computer component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. A “thread” is the entity within a process that the operating system kernel schedules for execution. As is well known in the art, each thread has an associated “context” which is the volatile data associated with the execution of the thread. A thread's context includes the contents of system registers and the virtual address belonging to the thread's process. Thus, the actual data comprising a thread's context varies as it executes.
Instances herein automate the process of obtaining arbitrary registration codes from a store where a software application is purchased and storing these registration codes in arbitrary locations designated by a software application. When the application is then run, it sees that the registration code has already been entered, and the user is never asked to manually enter it, substantially increasing user satisfaction. For example, instances herein can be used to gain the ability for an application catalog distributor to provision the registration codes directly on a mobile device. This makes the installation user experience more pleasant and faster as the end user does not need to wait to receive the registration code (e.g., through email/SMS), and the end-user does not need to enter the registration code on a device with limited input. After the application is installed and registration codes are registered by the catalog application, the end-user can just start using the application.
In
Thus, in one example, the client-side software registration component 102 can retrieve the software registration information 104 from the same server from which a client has downloaded a desired software application. This allows the software registration information 104 to pass to the client in a seemingly transparent fashion along with the desired software application. The client-side software registration component 102 then automatically processes the software registration information 104, extracts a software registration code, and provides the stored registration code 106. The stored registration code 106 is stored in a location that is determined from the software registration information 104 and is generally application-specific. The stored registration code 106 can also be comprised of multiple codes that are stored in multiple locations. The stored locations are typically known by the software application and are checked upon startup to authorize the running of the software application.
Because the client-side software registration component 102 resides on the client, the processing of the software registration information 104 is completed automatically without requiring intervention by an end-user of the software application. This allows the end-user to begin using their downloaded software application almost immediately without having to wait for registration codes to be emailed or sent to them. This is especially useful with mobile products such as, for example, mobile phones where entry of cryptic registration codes is not easily performed due to limited input capabilities. The automatic software registration system 100 also eliminates human error and/or ambiguities when entering registration codes. This drastically reduces the technical support necessary to get the software application up and running. If an end-user can immediately start using their downloaded software without waiting for codes or dealing with technical support, their satisfaction with the software product will be substantially increased.
Turning to
The software registration decoder 208 obtains the software registration information 204 and decodes it 204 to extract the registration code or codes. The software registration decoder 208 can also extract related information such as, for example, registration code storage locations, related software products, and/or versions and the like. For example, the software registration information 204 can be embedded using extensible markup language (XML) and automatically extracted by the software registration decoder 208 residing on the client. The registration code storage component 210 then receives, at a minimum, the registration code and registration code storage location information from the software registration decoder 208. The registration code storage component 210 then stores the registration code in the extracted storage location to provide the stored registration code 206. If multiple registration codes are present, the registration code storage component 210 can store them in their respective storage locations. Properly stored registration codes allow a client-side software application to check the appropriate locations for authorization to run. The storage locations can be local and/or remote to the client-side software application. This allows remote storage of all registration codes for security and/or ease-of-access and the like. For example, the remote storage location can reside on a remote server accessible via the Internet and the like.
Looking at
The server-side software registration component 304 provides the client-side software registration component 302 with software registration information formulated for a particular independent software vendor (ISV) 306. The server-side software registration component 304 can communicate the software registration information to the client-side software registration component 302 via, for example, the Internet (i.e., global communication system), an Intranet, a wired means, and/or wirelessly (e.g., via satellite, microwave, radio wave, etc.) and the like. Similar communication means can also be utilized between the server-side software registration component 304 and the independent software vendor (ISV) 306.
The ISV registration mechanism component 310 obtains an ISV registration mechanism from the independent software vendor (ISV) 306. The ISV registration mechanism is a means for ISVs to tailor their registration processes for individual software distributors and/or software applications in a standardized fashion. This also allows identification and/or tracking of the sources of the ISV software applications (very useful when the software application is being illegally used and/or distributed). The software registration mechanism is typically comprised of a registration code algorithm with various input parameters to specialize the registration code. The parameters can include, for example, a distributor ID, date of purchase, software application, version of the software application, etc. The independent software vendor (ISV) 306 can send the ISV registration mechanism to their distributors and/or the distributors can, for example, poll an ISV's server for the correct ISV registration mechanism.
Once the ISV registration mechanism component 310 has obtained the ISV registration mechanism it is made available to the software registration encoder 312. The software registration encoder 312 employs the ISV registration mechanism to encode at least one registration code to send to the client-side software registration component 302. The software registration encoder 312 can utilize, for example, XML to send the software registration information to the software registration decoder 314 of the client-side software registration component 302. The server-side software registration component 304 thus provides a unique registration process that is tailored for a particular software distributor and ISV.
As noted supra, the software registration decoder 314 automatically decodes the software registration information and provides the registration codes and/or registration storage locations to the registration code storage component 316. The registration code storage component 316 then automatically stores the registration code or codes in appropriate locations to provide the stored registration code 308. The entire server-side and client-side process can be fully automated so that the ISVs need only prepare appropriate registration mechanisms for distributors and make them available. This allows ISVs to concentrate on developing software applications instead of distributing their software. The ISV is also no longer responsible for maintaining and/or allocating registration codes with the instances disclosed herein, saving the ISVs substantial time and effort.
Referring to
In this example, an ISV software application 410 that is stored on the client reads the stored registration code 408 upon startup to determine if it is authorized to run. Thus, in this example, the client-side software registration component 406 and the ISV software application 410 are not required to interact directly. In other instances, however, additional information and/or validation and the like can occur between the client-side software registration component 406 and the ISV software application 410. Likewise, if desirable, the ISV software application 410 can still interact with the independent software vendor (ISV) 402. The instances disclosed herein provide automated solutions to third party software registration with the flexibility to allow integration with and/or replacement of existing registration processes, allowing other manual modes to be utilized as a back-up process, etc.
In
Looking at
Thus, when software is purchased through an application designed to enable the discovery, purchase, and download of software (a “catalog client”), the process of retrieving and entering registration codes can be 100% automated. APIs can be utilized to establish a process where the registration occurs transparently by establishing a communication protocol between ISVs and distributors. The registration mechanisms provided herein can consist of a set of private methods that can be used to register applications from a given distributor and a schema that distributors can use to provide registration information. In one instance, the client application then receives a set of registration codes in a specialized registration markup language. This specifies registration codes, their data type, and where they can be stored. Upon receipt, this XML node is parsed, and the specified registration codes are written to the specified locations. When the purchased software is executed, it sees these registration codes and end users are never prompted to enter them manually.
In view of the exemplary systems shown and described above, methodologies that may be implemented in accordance with the embodiments will be better appreciated with reference to the flow charts of
The embodiments may be described in the general context of computer-executable instructions, such as program modules, executed by one or more components. Generally, program modules include routines, programs, objects, data structures, etc., that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various instances of the embodiments.
Turning to
Referring to
It is to be appreciated that the systems and/or methods of the embodiments can be utilized in software registration facilitating computer components and non-computer related components alike. Further, those skilled in the art will recognize that the systems and/or methods of the embodiments are employable in a vast array of electronic related technologies, including, but not limited to, computers, servers and/or handheld electronic devices, and the like.
What has been described above includes examples of the embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations of the embodiments are possible. Accordingly, the subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
