REVENUE ORIENTED PATENT PORTFOLIO MANAGEMENT

Abstract

This disclosure comprises a method and system to automatically provide important business information to a user of the system at key decision making times during the lifetime of a patent with the goal of aligning business and strategies. The system will include an interface for the client to input information regarding business strategy on a continual basis and another interface to present the compiled information to the client at a later time, or to the working attorney. That information will be automatically sent to key decisions makers throughout the lifetime of a patent. Specifically, the business strategy information will consist of a revenue contribution ranking for client products as well as the competitors' products for each geographic region for which the invention is to be made, sold or transported.

Description

RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. 119(e) of U.S. Provisional Patent Application Ser. No. 61/542,545 filed Oct. 3, 2011, which is incorporated herein by reference in its entirety and made a part hereof. This application also claims the benefit under 35 U.S.C. 119(e) of U.S. Provisional Patent Application Ser. No. 61/561,502 filed Nov. 18, 2011, which is incorporated herein by reference in its entirety and made a part hereof.

BACKGROUND

The management of a patent portfolio involves multiple stages. Initially, a decision is made as to what inventions are worth the investment of filing a patent application. Then, each filed patent application goes through prosecution with the patent office. Finally, for each patent that is allowed, maintenance fees must be paid at a variety of intervals to keep the patent in force.

Throughout the multiple stages of the management of a patent portfolio the need can arise to align a client's business strategy with the management strategies of the portfolio. Often times this presents a problem because the business managers who develop and understand the business strategies of the client are not in communication with those who are responsible for the management of the patent portfolio. Those responsible for management of patent portfolios are then left either to make an uninformed decision or a decision that may be lacking information regarding the particulars of the client's business strategy. The embodiments disclosed herein, which will be discussed in detail below, seek to address the problem of aligning business strategy and patent portfolio management decisions.

BRIEF DESCRIPTION OF DRAWINGS

Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:

FIG. 1 is a system component diagram, according to an example embodiment.

FIG. 2 is a block diagram of a revenue oriented IP management environment, according to an example embodiment.

FIG. 3 is a block diagram of revenue oriented IP management architecture, according to an example embodiment.

FIG. 4 is a diagram depicting a multidimensional array of business strategy information, according to an example embodiment.

FIG. 5 is a flow chart depicting example operations of a revenue oriented IP management system according to an embodiment.

FIG. 6 is an example representation of a user interface of the revenue oriented patent portfolio management system.

FIG. 7 is an example representation of a user interface of the patent management system.

FIG. 8 is a block diagram of machine in the example form of a computer system within which a set instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed.

DETAILED DESCRIPTION

The lifecycle of a patent may include multiple stages. These stages generally include invention, filing a patent application on the invention, prosecuting the patenting application to allowance or abandonment, determining whether to file any continuing applications, and paying maintenance fees on the allowed patent.

At each stage, one or more parties determine the best course of action to take with respect to the invention. For example, when determining whether or not to file a patent, the inventor may know what products are out in the technology area of the invention, a business manager may know how the invention fits in with a company's goals, and a patent attorney may have researched existing patents or applications in the technology area of the patent. These parties will ultimately make the decision whether it is worth the initial investment of filing an application on the invention and then at each future stage determine the next course of action.

In various embodiments, a patent management system includes tools to help the parties involved in the patenting process make decisions at each stage of a patent's lifetime. These tools may also be used for general research by parties not immediately involved with the patenting of the invention. Additionally, these tools may be used as standalone tools, in combination with other tools, and in combination with other patent management systems. Examples of tools include, but are not limited to prosecution analytics, reference management, prior art analytics, docketing management, claim mapping, claim analytics, portfolio analytics, external database (e.g., PAIR) analytics, and annuity management.

According to one embodiment of this invention, important business strategy information will be provided to a user of the patent management system at key decision making times during the lifetime of a patent with the goal of aligning business and patent portfolio management strategies.

The patent management system will include an interface for a business manager to input information regarding business strategy on a continual basis. The system will include another interface to present the compiled information to a key decisions maker (e.g. the patent attorney prosecuting the patent) at each stage of a patent to assist the user in determining the next course of action. The business strategy information will be sent to the key decision maker throughout the lifetime of a patent (i.e. invention harvest through post prosecution) at each key decision making time (e.g. maintenance fee payment due date). Specifically, the business strategy information will consist of revenue contribution ranking information for matters in a patent portfolio as well as for the competitors to the owners of the patent portfolio. Revenue contribution ranking information for each matter and each competitor's matter will be associated with at least one technology category and at least one geographic region for which the invention is to be made, sold or transported.

FIG. 1 is a schematic view of computer network system 100 according to various embodiments. The computer network system 100 includes patent management system 102 and user terminal 104 communicatively coupled via network 106. In an embodiment, patent management system 102 includes web server 108, application server 110, database management server 114, which may be used to manage at least operations database 116 and file server 118. Patent management system 102 may be implemented as a distributed system; for example, one or more elements of the patent management system 102 may be located across a wide-area network from other elements of patent management system 102. As another example, a server (e.g., web server 108, file server 118, database management server 114) may represent a group of two or more servers, cooperating with each other, provided by way of a pooled, distributed, or redundant computing model.

Network 106 may include local-area networks (LAN), wide-area networks (WAN), wireless networks (e.g., 802.11 or cellular network), the Public Switched Telephone Network (PSTN) network, ad hoc networks, personal area networks (e.g., Bluetooth) or other combinations or permutations of network protocols and network types. The network 106 may include a single local area network (LAN) or wide-area network (WAN) or combinations of LAN's or WAN's, such as the Internet. The various devices/systems coupled to network 106 may be coupled to network 106 via one or more wired or wireless connections.

Web server 108 may communicate with file server 118 to publish or serve files stored on file server 118. Web server 108 may also communicate or interface with the application server 110 to enable web-based applications and presentation of information. For example, application server 110 may consist of scripts, applications, or library files that provide primary or auxiliary functionality to web server 108 (e.g., multimedia, file transfer, or dynamic interface functions). Applications may include code, which when executed by one or more processors, run the tools of patent management system 102. In addition, application server 110 may also provide some or the entire interface for web server 108 to communicate with one or more of the other servers in patent management system 102 (e.g., database management server 114).

Web server 108, either alone or in conjunction with one or more other computers in patent management system 102, may provide a user-interface to user terminal 104 for interacting with the tools of patent management system 102 stored in application server 110. The user-interface may be implemented using a variety of programming languages or programming methods, such as HTML (Hypertext Markup Language), VBScript (Visual Basic® Scripting Edition), JavaScript™, XML® (Extensible Markup Language), XSLT™ (Extensible Stylesheet Language Transformations), AJAX (Asynchronous JavaScript and XML), Java™, JFC (Java™ Foundation Classes), and Swing (an application programming interface for Java™).

User terminal 104 may be a personal computer or mobile device. In an embodiment, user terminal 104 includes a client program to interface with patent management system 102. The client program may include commercial software, custom software, open source software, freeware, shareware, or other types of software packages. In an embodiment, the client program includes a thin client designed to provide query and data manipulation tools for a user of user terminal 104. The client program may interact with a server program hosted by, for example, application server 110. Additionally, the client program may interface with database management server 114.

Operations database 116 may be composed of one or more logical or physical databases. For example, operations database 116 may be viewed as a system of databases that, when viewed as a compilation, represent an “operations database.” Sub-databases in such a configuration may include a matter database, a portfolio database, a user database, a mapping database, an analytics database and a business strategy information database. Operations database 116 may be implemented as a relational database, a centralized database, a distributed database, an object oriented database, or a flat database, in various embodiments.

In various embodiments, the tools of the patent management system 102 share a common framework. The framework may have a base organization unit of a matter. In various embodiments, a matter is an issued patent or patent application that includes one or more patent claims. In an embodiment, a matter is generally identified by its patent number or publication number. Identification may mean either identification as it relates to a user of the patent management system 102 or within the patent management system 102. Thus, a user may see a matter listed as its patent number while internally a database of the patent management system 102 may identify it by a random number. One or more matters may be associated with prior art or cited references stored in a reference or prior art database. Data stored in a first database may be associated with data in a second database through the use of common data fields. For example, consider entries in the matter database formatted as [Matter ID, Patent Number] and entries in the portfolio database formatted as [Portfolio ID, Matter ID]. In this manner, a portfolio entry in the portfolio database is associated with a matter in the matter database through the Matter ID data field. In various embodiments, a matter may be associated with more than one portfolio by creating multiple entries in the portfolio database, one for each portfolio the matter is associated with. In other embodiments, one or more patent reference documents may be associated with a patent by creating multiple entries in the patent database, for example.

During operation of patent management system 102, data from multiple data sources (internal and external) is imported into or accessed by the operations database 116 (FIG. 1). Internal sources may include data from the various tools of the patent management system 102. External sources 120 (FIG. 1) may include websites or databases associated with foreign and domestic patent offices, assignment databases, WIPO, and INPADOC. In various embodiments, the data is scraped and parsed from the websites if it is unavailable through a database. The data may be gathered using API calls to the sources when available. The data may be imported and stored in the operations database 116 (FIG. 1) on a scheduled basis, such as weekly, monthly, quarterly, or some other regular or periodic interval. Alternatively, the data may be imported on-demand.

After data importation, the data may be standardized into a common format. For example, database records from internal or external sources may not be in a compatible format with the operations database. Data conditioning may include data rearrangement, normalization, filtering (e.g., removing duplicates), sorting, binning, or other operations to transform the data into a common format (e.g., using similar date formats and name formats).

FIG. 2 is an illustration of example architecture 200 of the common framework used to organize matters in the patent management system 102 (FIG. 1). The structure of the database and format and data field titles are for illustration purposes and other structures, names, and formats may be used. Additionally, further associations between data stored in the databases may be created as discussed further herein.

Client node 202 represents a client user of the patent management system 102 (FIG. 1) having multiple patent portfolios 204 managed by the system 102. One or more matters may be grouped together to form a portfolio 204. Each portfolio 204 may contain either one or more sub-portfolios 204a or one or more technology categories 206, depending on the requirements of the client. A sub-portfolio 204a allows for further delineation of matters based upon a more specific area of interest within a portfolio 204.

Each matter 212 within a portfolio 204 or sub-portfolio 204a is further organized into one or more technology categories 206. Technology categories 206 may be general or may be specifically defined by each client user of the patent management system 102 (FIG. 1).

Each matter 212 may also be associated with one or more other matters 212 in a family 208. Family members may be determined according to a legal status database such as INPADOC.

Each family 208 member may have a number of associated regional family applications 210. For example, the first group of applications in regional family application 210 is a grouping of a family 208 of applications for the United States region. Matters 212 are each found within the Unites States regional family 208. Each matter within the regional family 210 may be a priority matter, or a continuing (e.g., continuation, divisional) matter.

FIG. 3 is a block diagram of patent management system 102 (FIG. 1), according to an example embodiment. Illustrated are user database 302, matter database 304, portfolio database 306, mapping database 308, business strategy database 310, display module 312, input module 314, mapping module 316, and comparative revenue ranking module 218. In various embodiments, the data stored in databases 302, 304, 306, 308, and 310 may be in the same or multiple physical locations. For example, portfolio database 306 may be stored in one or more computers associated with a portfolio management service. In various embodiments, patent management system 102 minors databases stored in other locations. In an embodiment, when a request is made to access data stored in the databases, patent management system 102 determines where the data is located and directs the request to the appropriate location. Similarly, modules 312-318 may be executed across multiple computer systems.

In an example embodiment of user database 302 stores data representing users of patent management system 102 (FIG. 1). The data may include data fields of user credentials including a user ID and password and access rights with respect to patent management system 102. The user ID may be common across the tools of the patent management system 102. In this manner, access rights of the user with respect to the tools of the patent management system 102 may follow the user across the various tools of the patent management system 102. In an example embodiment, different access rights are granted to a user ID between the various tools.

In various embodiments, each user ID has access rights to one or more matters (e.g., matters 212). Similarly, a user ID may have portfolio level access rights. Access rights may be defined according to at least two parameters: read access and write access. Thus, when a user logs into patent management system 102 (FIG. 1), the user is presented with access only to the matters/portfolios that have been associated with that user's user ID. More (e.g., additional contact information) or fewer data fields associated with a user may be included in a user entry stored in user database 302.

In an embodiment, matter database 304 stores data representing matters (e.g., matters 212). Each matter may be associated with one or more portfolios (e.g., portfolios 204) as well as a comparative revenue ranking, one or more technology categories (e.g., technology categories 206), one or more competitors, and one or more geographic regions. In some embodiments, a matter is associated with no portfolios. In various embodiments, a matter is a foreign or domestic patent or application. Matters may also pertain to inventions that have not yet been filed (e.g., as may be the case within a docketing system). In an embodiment, a matter entry includes data fields representing a matter ID, patent number, publication number, serial number, docketing number, title (e.g., the name of the patent or application), type of the matter (e.g., application, issued patent, PCT application), status of the matter (e.g., issued, abandoned, allowed), a link to the patent office where the matter was filed, a link to a PDF download of the matter, abstract of the matter, inventors of the matter, current owner of the matter, cited references on the face of the matter, filed date, issue date, docket number, and annuity information (e.g., due date, country, and amount due). In some embodiments, other patent reference documents or prior art in any form may be stored and associated with one or more matters. More or fewer data fields associated with a patent may be included in a matter entry stored in matter database 304. In an example embodiment, matter database 304 may store a patent matter database, wherein this database includes data about the patent matters 212. The data may include, for at least one patent matter, a claim set or statement of invention and a priority date for the claim set or statement of invention. Matter database 304 may also store a database of prior art documents (also known as “references”), wherein the prior art database includes data about the prior art documents. The data may include, for at least one prior art document, a priority date or publication date of the document. One or more of the prior art documents may be associated with a first patent matter in the patent matter database 304.

In various embodiments, a matter is associated with one or more other matters as a family (e.g., family 208) with a family ID. Family members may be priority documents, continuation patents/applications, divisional patents/applications, and foreign patent/application counterparts. In an embodiment, family information is determined according to an external source such as INPADOC. Patent reference documents and/or other prior art may be manually or automatically stored, cross-cited and associated with related family matters, for example.

Portfolio database 306, in an example embodiment, stores data representing portfolios of one or more matters. Data stored in portfolio database 306 may have been previously generated by a tool of patent management system 102 (FIG. 1). In various embodiments, a portfolio 204 may be generated by a user using patent management system 102. For example, a user interface may be presented to the user requesting a name for the portfolio 204 and identifiers of matters 212 to be included in the portfolio 204. In an embodiment, a portfolio entry in portfolio database 306 includes data fields of portfolio ID and portfolio name. Additionally, a data field for matter ID may also be included in an entry in the portfolio database 306. Thus, each portfolio 204 may be associated with one or more matters 212 through the use of the matter ID data field. More or fewer data fields associated with a portfolio 204 may be included in a portfolio entry of portfolio database 306.

In various embodiments, mapping module 316 is configured to facilitate mappings of scope concepts, technology categories 206, and keywords to patent claims of a matter 212 (FIG. 2). In an embodiment, mapping signifies association. For example, in conjunction with display module 312 and input module 314, mapping module 316 may present a user interface of patent claims stored in matter database 304 and scope concepts stored in mapping database 308. Input module 314 may receive a selection of one or more patent claims and one or more scope concepts and pass them to mapping module 316. Mapping module 316 may then formulate an SQL query to associate the one or more patents claims with the one or more scope concepts. When executed, the SQL query may update the mapping database 308 with the associations. In various embodiments, mapping module 316 also allows the creation of new scope concepts, technology categories 206, and keywords that may be mapped to one or more patent claims. Furthermore, mapping module 316 may present user interfaces that allow a user to rank and rate matters 212 stored in matter database 304.

Mapping module 316 may also allow the generation of claim charts of a plurality of cells. A claim chart may include one or more scope concepts, technology categories 206 (FIG. 2), and keywords on one axis and claims of matters 212 in a portfolio 204 (FIG. 2) on the other axis. The claim chart may include a variety of levels of granularity of scope concepts. Some claims may be mapped to all of the scope concepts while others may not be mapped to any scope concepts. At the cell intersection between a scope concept (or technology category 206 or keyword) and a claim, an indication of the mapping may be presented by changing the format of the cell. For example, the cell may be colored blue when a scope concept is mapped and red when not mapped.

In an example embodiment, business strategy database 310 includes comparative revenue ranking information for technology categories 206, competitors, and geographic regions to one or more matters 212 (FIG. 2). In one embodiment, technology category information may indicate a matter is in a certain technology area. Each patent portfolio 204 (FIG. 2) may contain numerous technology categories 206. Each matter may be associated with multiple technology categories 206. For example, a patent portfolio for a client bicycle manufacturing company may include technology categories 206 for frames, brakes, gears, handlebars and wheels.

Competitor information includes comparative revenue ranking information for the competitors of the owner of one or more matters. Competitor information will include the direct, indirect and benchmark competitor to the owner of each matter. Direct competitors are those whose business or products compete directly with the scope of a matter. For example, direct competitors for the owners of a patent portfolio for a bicycle manufacturer client may include Trek Bicycle Corporation, Specialized, and Giant Bicycles.

Indirect competitors do not compete directly with an owner of a matter or portfolio, however, an indirect competitor will nonetheless affect the scope of a matter. For example, a bicycle manufacturing client with a new patent covering technology for battery powered electronic bicycles may have an indirect competitor in a business specializing in long lasting batteries for hybrid vehicles, such as Tesla Automotive.

Likewise, a benchmark competitor does not compete directly or indirectly with an owner of a matter, but rather the competitor is a company whose profile and success is compared with the success of an owner's matter or portfolio. For example, a client bicycle manufacturer may have Apple Inc. listed as a benchmark competitor. Even though Apple Inc. does not compete in the same industry as the bicycle manufacturer it may nonetheless provide helpful metrics for the client bicycle manufacturer to compare itself against.

A geographic region mapping may indicate a claim is to be sold or manufactured in a particular geographic region or regions. For example, a client bicycle manufacturer may wish to sell their bicycles in the United States but have them assembled in China. In such an example, the client bicycle manufacturer would have both the United States and China revenue ranking information for matters in their portfolio.

In various embodiments, business strategy database 310 stores data representing a comparative revenue ranking of matters (e.g., matters 212) stored within patent management system 102 or external data sources 120 (FIG. 1). In various embodiments, comparative revenue rankings are organized according to the technology category, geographic regions and competitors associated with an individual product, an individual matter (e.g. matters 212), a portfolio (e.g., portfolio 204), or family (e.g., family 208). The comparative revenue rankings are may be based on information gathered from a client's competitive analysts or from multiple other sources such as databases of patent management system 102 and PAIR.

Comparative revenue ranking information is a scaled representation of the matter or portfolio's revenue contribution to the overall revenue of the client. In one embodiment, comparative revenue ranking information is represented on a scale from 1 to 10. Comparative revenue ranking is not a percentage of revenue generated by a specific production, but rather a ranking of importance of the contribution to the client's overall revenue or the client's competitors overall revenue.

In various embodiments, portfolio and family comparative revenue ranking information may be stored in business strategy database 310 based on aggregating the metrics for an individual matter. In an embodiment, the revenue rankings of a family may differ from those in a portfolio as not all family member matters may be part of a portfolio. Additionally, the revenue rankings should be updated when the information changes, however, information may be stored for multiple time periods such that comparisons may be made between current rankings and rankings from a year ago (or other time period).

In an embodiment, display module 312 is configured to display user interfaces and information retrieved from one or more databases 302-310. If a user is accessing patent management system 102 (FIG. 1) remotely, (e.g., through a web browser) display module 312 may be configured to transmit data representing a user-interface through a network to a user terminal. In various embodiments, display module 312 is configured to generate one or more charts of data stored in databases 302-310. For example, display module 312 may generate a pie chart of the top 10 inventors within a portfolio 204 (FIG. 2).

In various embodiments, input module 314 receives data from multiple sources where it may be further processed by one or more other modules and stored in one or more of databases 302-310. For example, input module 314 may be configured to utilize one or more APIs to access data from one or more patent data stores (e.g., public PAIR, private PAIR, INPADOC, foreign patent offices, patent docketing systems, portfolio management systems, etc). The data may include published patent documents, patent applications, office actions or other patent office correspondence, prior art references, claim mappings, dockets dates, annuity payment data.

In various embodiments, input module 314 is configured to receive input from one or more user interface elements. For example patent management system 102 (FIG. 1) may present multiple user interfaces to a user. These user interfaces may enable users to input data directly into databases 302-310, instruct the patent management system 102 to retrieve data from patent data stores, and instruct the patent management system 102 to perform various operations (e.g., analysis) on the data in databases 302-310. In one embodiment, the input module 314 is configured to receive business strategy information from one or more user interface elements (e.g., user interface 600).

Additionally, input module 314 may be configured to determine the selection of one or more user interface elements by a user and initiate the action associated with the selected user interface element. For example, a user interface element may include a drop-down menu to select a portfolio (e.g., portfolio 204). Input module 314 may be configured to receive the selection of the portfolio by the user. Then, input module 314 may pass the selection to one or more other modules for further processing. For example, display module 312 may update the drop-down menu to indicate the selection of the portfolio.

In various embodiments, input module 314 processes the data that has been inputted and formats it according to the data fields of databases 302-310 as discussed above. Is various embodiments, processing is completed using a parsing module (not shown). For example, consider a patent publication that a user has directed to be input into one or more of the databases. The processing module may use a combination of automatic image recognition and text analysis to determine the filing date, issue date, title, abstract, and claims of the patent. In some embodiments, the parsing module may flag certain pieces of data that had been determined to be potentially inaccurate (e.g., a number could not be read). A user of patent management system 102 (FIG. 1) may then examine the flagged data and manually enter the information which is then stored in the appropriate database.

The resulting data that has been parsed by the parsing module may then be entered as an entry in one or more of databases 302-310. This may be accomplished by, for example, formulating an insert SQL query with the parsed information. In various embodiments, the parsing module may parse multiple piece of information before generating a database entry. For example, input module 314 may receive a docket number for an issued patent. The docket number may be combined with the information parsed from the issued patent to form an entry in matter database 304.

In various embodiments, mapping module 316 is configured to facilitate mappings of scope concept, technology categories, and keywords to patent claims of a matter. In an embodiment, mapping signifies association. For example, in conjunction with display module 312 and input module 314, mapping module 316 may present a user interface of patent claims stored in matter database 304 and scope concepts stored in mapping database 308. Input module 314 may receive a selection of one or more patent claims and one or more scope concepts and pass them to mapping module 316. Mapping module 316 may then formulate an SQL query to associate the one or more patents claims with the one or more scope concepts. When executed, the SQL query may update the mapping database 308 with the associations. In various embodiments, mapping module 316 also allows the creation of new scope concepts, technology categories, and keywords that may be mapped to one or more patent claims. Furthermore, mapping module 316 may present user interfaces that allow a user to rank and rate matters stored in matter database 304.

Mapping module 316 may also allow the generation of claim charts of a plurality of cells. A claim chart may include one or more scope concepts, technology categories, and keywords on one axis and claims of matters in a portfolio on the other axis. The claim chart may include a variety of levels of granularity of scope concepts. Some claims may be mapped to all of the scope concepts while others may not be mapped to any scope concepts. At the cell intersection between a scope concept (or technology category or keyword) and a claim an indication of the mapping may be presented by changing the format of the cell. For example, the cell may be colored blue when a scope concept is mapped and red when not mapped.

FIG. 4 illustrates an example architecture 400 of the multidimensional business strategy database 310. Each cell within the business strategy database 310 contains aggregated data related to elements along each of its dimensions. As illustrated by architecture 400, each cell within the business strategy database 310 contains a comparative revenue ranking for either a client matter or competitor matter that is associated with a certain technology in a certain geographic region.

For example, cell 402 is a cell within the business strategy database 310 containing comparative revenue ranking data 404. According to this embodiment, cell 402 has stored comparative revenue ranking data 404 for a client matter associated with Technology 1 in the geographic region of the United States.

Column 406 represents the entire vertical column of cells containing the comparative revenue ranking for the client. Within column 406 is all the comparative revenue ranking data for every technology category (Technology 1, Technology 2, Technology 3, and Technology 4) in a client portfolio (e.g., portfolio 204) further organized by every geographic region (US, KR, EU, and AZ) that each technology category (e.g., technology category 206) is to be sold or manufactured in.

Similar to column 406, column 408 represents the entire vertical column of comparative revenue ranking data for Competitor A. Just as with the client (column 406), the business strategy database 310 contains data for Competitor A for each technology category 206 in the client's portfolio 204, for every region that the technology is to be sold or manufactured in. Likewise, columns 410 and 412 represent the comparative revenue ranking data for each Competitor B and Competitor C. Column 410 and 412 are stored and maintained in the same manner as the cells found in column 406 and 408.

FIG. 5 is example operation 500 of the revenue oriented patent portfolio management system. At block 502, the system receives the business strategy information from a business manager familiar with the client's business strategy for a particular technology in at least one geographic region. The business strategy information received by the system comprises comparative revenue ranking information for client matters for at least one defined technology category, in at least one selected geographic region. The business strategy information further comprises comparative revenue ranking information for direct, indirect and benchmark competitors to an owner. As the information changes, the revenue oriented patent portfolio management system receives updated business strategy and revenue ranking information.

In one embodiment, the business strategy information received by the revenue oriented patent portfolio management system is associated with every matter (e.g., matters 212) in the client's patent portfolio (e.g., portfolio 204). In another embodiment, the business strategy information received by the revenue oriented patent portfolio management system is associated with only a certain family of patent portfolio matters in the patent portfolio.

At block 504, the information received by the business manager is used to populate the business strategy database 310. In one embodiment, the business strategy database 310 is constructed and populated as illustrated by example architecture 400.

At block 506, the revenue oriented patent portfolio management system will detect the occurrence of the need of a decision maker to take action on a particular matter. This occurrence is a key event in the lifetime of the patent. The revenue oriented patent portfolio management system will monitor a matter throughout the lifetime of the matter and may detect the occurrence of a need to make a key decision multiple times throughout the lifetime of a matter. For example, during the prosecution of a patent matter, the revenue oriented patent portfolio management system may detect the need to decide whether a continuation application should be filed for a given matter. Other examples of a key event in the lifetime of a patent include the decision whether to pay a maintenance fee for a matter, the decision to file an appeal of a final office action or the decision to abandon a patent application.

Once a key decision making situation has been detected, the system will automatically provide a user of the system with the business strategy data contained in the business strategy database 310 at block 508. For example, if a matter in post issuance in the United States has an upcoming maintenance fee due the system will prompt a user with business strategy information for that matter. The business strategy information will include the comparative revenue ranking information for all the technology categories associated with that matter for the United States as well as the same information for each of the competitors to the owner for that matter.

In one embodiment, the system provides a user with the business strategy data via a user interface (e.g., user interface 700). In another embodiment, the system provides a user with the business strategy data via an email sent to the user.

At block 510, the system provides a user with the ability to complete the action for which the system has provided business strategy information. By way of non-limiting example, this may include the ability to file a new application for a matter, file an appeal for a matter having received a final office action, abandon filing, or pay a maintenance fee. In one embodiment, the system provides an actionable link to the decision maker to complete the action for the particular patent portfolio matter based on the business strategy information. The actionable link may provide the user with a selectable link to indicate the desired action made by the decision maker or the actionable link may redirect the decision maker to another site where the action may be taken.

FIG. 6 is an example user interface 600 of the revenue oriented patent portfolio management system which may be used to facilitate the input of business strategy information from a client business analyst. User interface 600 is illustrated with multiple user interface and input elements. In an example embodiment, a user interface element is a graphical or textual element that a user may interact with to cause an application to perform an assigned action for the interface element. Data representing user interface 600 may be transmitted via network 106 and presented on a display of user terminal 104 (FIG. 1) through the use of a web browser. A user (e.g., manager of a patent portfolio) may interact with the user interface elements of user interface 600 through the use of an input device (e.g., stylus, cursor, mouse, finger) of the user terminal. In an embodiment, a user selection is based on the coordinates of the input device as it makes contact with the display or where a user “clicks” the mouse. The coordinates are compared to the coordinates of the user input element to determine the selection. The type of user elements, names, and layout depicted in FIG. 6 are intended to be an illustration of an example user interface of patent management system 102 (FIG. 1).

The user interface elements may include technology category 602, organization 604, geographic region 606, and comparative revenue ranking 608. These elements may be used to select and input the information relevant to the revenue oriented patent portfolio management system. A user may select a technology category 602 from the drop menu or define a new technology category. Similarly, a user may select the organization 604 (i.e. either the client or a client's competitor) and geographic region 606 from the respective drop down menus or the user may add a new competitor or geographic region.

The comparative revenue ranking 608 for a given set of technology category 602, organization 604, and geographic region 606 may be selected from the drop down menu or may be manually input from a user input device (e.g. keyboard).

FIG. 7 is an example user interface 700 of patent management system 102 (FIG. 1) which may be used to facilitate the methods, tools and systems described herein. User interface 700 is illustrated with multiple user interface elements. In an example embodiment, a user interface element is a graphical or textual element that a user may interact with to cause an application to perform an assigned action for the interface element. Data representing user interface 700 may be transmitted via network 106 and presented on a display of user terminal 104 (FIG. 1) through the use of a web browser. A user (e.g., manager of patent portfolio 204) may interact with the user interface elements of user interface 700 through the use of an input device (e.g., stylus, cursor, mouse, finger) of the user terminal. In an embodiment, a user selection is based on the coordinates of the input device as it makes contact with the display or where a user “clicks” the mouse. The coordinates are compared to the coordinates of the user input element to determine the selection. The type of user elements, names, and layout depicted in FIG. 7 are intended to be an illustration of an example user interface of patent management system 102. Other types of user elements, names, and layouts may be used.

Date boxes 708 and 710 are user elements that allow a user to select a time period. Amount due box 712 displays the amount due with respect to annuities for patents in the portfolio of the user within the period indicated by date boxes 708 and 710. Upon activating (e.g., clicking) one of the date boxes, a user may be presented with a calendar which allows the selection of a date. Upon selecting a date, the date boxes 708 & 710 will update to reflect the user's choice.

Drop-down menu 714 includes a list of portfolios (e.g., portfolio 204) that a user of the patent management system 102 (FIG. 1) is authorized to view. For example, before user interface 700 is displayed, a login screen may be presented to the user which requests a user ID and password. In various embodiments, the user ID is associated with one or more portfolios. In turn, each portfolio is associated with one or more matters (e.g., matters 212). Matters may include US and foreign issued patents, pending patents, abandoned patents, and not yet filed applications. For example, upon selection of a portfolio 204 using drop-down menu 714, user interface 700 is populated with matters 212 associated with the portfolio 204.

Checkbox 716 is an option to only display matters that currently have an annuity due. Drop-down menu 718 allows further filtering of matters. For example the matters may be filtered by US patents only, US patent applications and foreign only.

In various embodiments, activation of button 720 updates user interface 700 to reflect the choices made by the user with respect to date boxes 708 and 710, checkbox 716, and drop-down menu 718. For example, amount due box 712 will be updated to reflect the amount due within the new period and the matters listed under column headings 722 may be filtered. In various embodiments, user interface 700 is updated as the user selections are made with respect to elements 708 to 718 without activating button 720.

Drop-down menu 724 presents business strategy information to the user if the matter is in state requiring an action by the user. The business strategy information presented to the user in drop-down menu 724 includes the comparative revenue ranking data for the technology category and geographic region for which the matter is associated along with comparative revenue ranking information for a client's competitors associated with the same technology category and geographic region.

Modules, Components and Logic

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more processors may be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein.

In various embodiments, a hardware-implemented module may be implemented mechanically or electronically. For example, a hardware-implemented module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the term “hardware-implemented module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware-implemented modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware-implemented module at one instance of time and to constitute a different hardware-implemented module at a different instance of time.

Hardware-implemented modules can provide information to, and receive information from, other hardware-implemented modules. Accordingly, the described hardware-implemented modules may be regarded as being communicatively coupled. Where multiple of such hardware-implemented modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware-implemented modules. In embodiments in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules have access. For example, one hardware-implemented module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)

Electronic Apparatus and System

Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.

A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.

Example Machine Architecture and Machine-Readable Medium

FIG. 8 is a block diagram of machine in the example form of a computer system 800 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system 800 includes a processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 804 and a static memory 806, which communicate with each other via a bus 808. The computer system 800 may further include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 800 also includes an alphanumeric input device 812 (e.g., a keyboard), a user interface (UI) navigation device 814 (e.g., a mouse), a disk drive unit 816, a signal generation device 818 (e.g., a speaker) and a network interface device 820.

Machine-Readable Medium

The disk drive unit 816 includes a machine-readable medium 822 on which is stored one or more sets of instructions and data structures (e.g., software) 824 embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 824 may also reside, completely or at least partially, within the main memory 804 and/or within the processor 802 during execution thereof by the computer system 800, the main memory 804 and the processor 802 also constituting machine-readable media 822.

While the machine-readable medium 822 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 824 or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions 824. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media 822 include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Transmission Medium

The instructions 824 may further be transmitted or received over a communications network 826 using a transmission medium. The instructions 824 may be transmitted using the network interface device 820 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived there from, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Abstract

The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims

1. A computer implemented method implemented by one or more processors, the method comprising:

receiving business strategy information including a comparative revenue ranking indicating a revenue contribution of a patent portfolio to an overall revenue of an owner of the patent portfolio;

detecting, using the one or more processors, a key event in the lifetime of a particular patent portfolio matter necessitating action by a decision maker; and

in response to the detecting of the key event, automatically providing the business strategy information for the particular patent portfolio matter to the decision maker.

2. The computer implemented method of claim 1, further comprising

providing an actionable link to the decision maker, the actionable link being a means to complete the action for the particular patent portfolio matter based on the business strategy information.

3. The computer implemented method of claim 1, further comprising

receiving updated business strategy information, based on a change in business strategy by a client.

4. The computer implemented method of claim 1, wherein the business strategy information further includes

at least one technology category for the patent portfolio,

at least one geographic region associated with the patent portfolio,

at least one competitor to an owner of the patent portfolio, and wherein the comparative revenue ranking indicates a revenue contribution of the patent portfolio to the at least one technology category, the at least one geographic region, and the at least one competitor of the patent portfolio.

5. The computer implemented method of claim 4, wherein the competitor to the owner of the patent portfolio is designated by the user and is selected from a list of direct, indirect or benchmark competitors to the owner.

6. The computer implemented method of claim 1, wherein the business strategy information is associated with every matter in the patent portfolio.

7. The computer implemented method of claim 1, wherein the business strategy information is associated with only a certain family of patent matters in the patent portfolio.

8. The computer implemented method of claim 1, wherein the key event is a decision to pay a patent maintenance fee.

9. The computer implemented method of claim 1, wherein the key event is a decision to file a continuation application for a patent.

10. The computer implemented method of claim 1, wherein the key event is a decision to file an appeal of a final office action.

11. The computer implemented method of claim 1, wherein the key event is a decision to abandon a patent application.

12. The computer implemented method of claim 1, wherein automatically providing business strategy information is accomplished via email.

13. The computer implemented method of claim 1, wherein automatically providing business strategy information is accomplished via a user interface of a patent management system.

14. The computer implemented method of claim 2, wherein the actionable link comprises a selectable indicator to indicate a desired action made by the decision maker.

15. The computer implemented method of claim 2, wherein the actionable link comprises a link to redirect the decision maker to another site where the action may be taken, based on the business strategy information provided to the user.

16. A system comprising

a processor of a machine;

a hardware-implemented input module configured to receive business strategy information including a comparative revenue ranking indicating a revenue contribution of a patent portfolio to an overall revenue of an owner of the patent portfolio;

a hardware-implemented business strategy database including a multidimensional array to store business strategy information received by the input module; and

a hardware-implemented display module configured to transmit business strategy information stored on the business strategy database to the user in response to detecting, using the processor of the machine, a key event in the lifetime of a particular patent portfolio matter necessitating action by a decision maker.

17. The system of claim 16, wherein the hardware-implemented display module is further configured to provide a user with an actionable link to complete the key decision based on the business strategy information transmitted to the decision maker.

18. The system of claim 16, wherein the business strategy information further includes at least one technology category, at least one competitor, at least one geographic region and wherein the comparative revenue ranking indicates a revenue contribution of the patent portfolio to the at least one technology category, at least one competitor, at least one geographic region.

19. A non-transitory machine readable medium having instructions embodied thereon, the instructions that, when executed by the machine, cause the machine to perform operations comprising:

receiving business strategy information including a comparative revenue ranking indicating a revenue contribution of a patent portfolio to an overall revenue of an owner of the patent portfolio;

detecting a key event in the lifetime of a particular patent portfolio matter; and

automatically providing, in response to the detecting of the key event, business strategy information for the particular patent portfolio matter to a user.