Data processing: financial – business practice – management – or co – Business processing using cryptography – Utility metering system
Reexamination Certificate
1995-11-20
2002-06-04
Trammell, James P. (Department: 2161)
Data processing: financial, business practice, management, or co
Business processing using cryptography
Utility metering system
C705S412000, C379S106030, C709S203000, C709S241000, C340S870020, C340S870410
Reexamination Certificate
active
06401081
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates to systems used in the utility industry. In particular, the invention relates to metering, network, database, and computer application systems used in the utility (i.e., gas, water, and electricity) industries.
Heretofore, it was common for the manufacturer of meters or other devices used in the utility industry to develop metering devices which could be read by certain, specific means, and which could be programmed, if at all, by certain specific means. By way of example, in the electricity industry, the manufacturer of a particular meter could include a register thereon which was capable of storing certain metering information, i.e., total KwHr metered, time of use information, maximum demand over some time period, etc. For each meter developed by each manufacturer, the way in which the data was retained in the meter and the manner in which data could be extracted from the meter was often unique to a particular meter. Thus, it was not only possible, but common, for there to be a variety of meters, manufactured by the same manufacturer which each retained somewhat different data in somewhat different formats, and it was common to have situations in which it was necessary to extract that data using a specific technique, which involved the use of a unique piece of software. By way of example, meters could be read using optical ports, direct (wired) connections, telephone modems, power line carrier (“PLC”) communications, radio (“RF”) means, etc. Further, each meter would typically use a different type of software to read and/or program features which were present in the meter. If that did not complicate matters enough, each manufacturer would typically develop its own communications “protocol” to communicate with the meters which it developed.
In the area of communications protocols alone, different meter manufacturers each approached the idea of a protocol somewhat differently. Thus, one manufacturer might define a communications protocol in a manner which allowed a particular command to extract a particular type of data from a particular meter. Yet another manufacturer might define the “protocol” as the communications method for communicating with the meter, and the meters of that manufacturer would typically retain data in each of its meters in particular memory locations. In order to program (or obtain data from) the latter type of meters, it was necessary to know both the protocol and the “memory map” which detailed the memory locations of the data within the meter.
In view of the numerous types of meters and the numerous meter manufacturers, the number of individual pieces of computer software which were needed by a utility to set up, program, and read meters continued to grow, much to the dismay of the utilities which found that they needed to maintain numerous pieces of computer software in order to accomplish the tasks which they had to regularly perform. Further, depending upon the size of the utility, the purpose of the software, and when the software was initially installed, utilities could find themselves operating software on a number of different platforms, which typically included UNIX®, MS-DOS, and WINDOWS.
In an effort to assist the utilities in limiting the number of different computer software packages which they had to maintain, suppliers to the industry started to provide so-called “multi-vendor” systems. Such multi-vendor systems, i.e., the Schlumberger Industries MULTI-MASTER® software or the Utility Translation System MV-90™ software, were able to communicate with the meters of more than one manufacturer. However, they, too, had problems, in that a number of manufacturers perceived the need to maintain their protocols and memory maps as trade secrets in order to prevent competitors from “cloning” their equipment and thereby trading upon the good will which they had established with their customers. This was a particularly troublesome problem in those instances in which an interloper appeared on the scene with a meter which they claimed to be a “clone” of a meter sold by an established manufacturer, and then only after buying the meter, would the utility learn that the “new” meter did not perform the same as the one which had been “cloned”.
Other problems with multi-vendor systems involved the fact that in order to develop such systems it was necessary for the system developer to have access to information which the meter manufacturer might consider to be proprietary. Accordingly, the development and marketing of a new meter often became difficult. It was difficult for the meter manufacturer, which had to have software support for its meter, because until the company doing the software support actually implemented the meter support in their software, and until the software was released, the utilities could not use the meter, so the manufacturer could not sell the meter. The meter manufacturers could not add the software support for new meters into existing multi-vendor systems due to the closed architecture which such systems employed. Similarly, the software support companies were continuously in a situation in which they were trying to implement support for new meters, while performing updates to their packages to further support meters already in the field.
From the utilities perspective, unless a meter had adequate system support, it could not be used. Even meters which were supported, could not always be used, if the system on which they were supported differed from the system which the particular utility was using. Thus, depending upon the computer platform which was used at a particular utility, the operating system being used on that platform, whether or not the utility had made a committment to the use of a particular multi-vendor computer software system, and the types of meters already in the utility, the utility's decision to purchase a particular meter could be greatly affected.
Finally, individual utilities would often find the need to have specialized computer application software developed to meet specific, internal needs of the utility. As there are many utilities which do not maintain their own internal programming staff, it was necessary for them to hire outside consultants to develop the applications software. For both those utilities which had an internal programming staff and those who used outside programmers it was necessary to obtain the communications protocol, and memory map information from the meter manufacturers to even begin to develop an application which could be used to generate even a simple report.
Thus, unless a utility chose to limit the number of types of meters which it would purchase, the types of computers on which it would operate its software, the particular databases which it maintained, and a host of other factors, all of which were limiting to the manufacturer's ability to meet specific needs, there was no easy way to address the issues of universal system compatibility. Even worse, each time another new type of meter or application or database engine or computer system was introduced, the problem of integrating the various items into an existing system grew exponentially.
In view of the foregoing problems, many utilities called for the manufacturers to develop a “standard” way of communicating with metering equipment. However, other manufacturers and utilities wanted to retain the ability to add additional features to the future metering equipment which they sought to manufacture and purchase. Consequently, there was no simple solution which was universally acceptable, and as new microprocessor based solid-state meters brought additional features to the market place, and as demand developed for automatic meter reading (“AMR”) equipment increased, the problems continued to mount.
In particular, utilities have turned to AMR systems in order to allow timely reads of customer's meters on a scheduled and/or demand basis, without requiring access to the customer premises. These systems are becoming increasingly complex as new features are a
Amikam Leor
Hastings Mark Alan
Howard Susanne Kristina Marie
MacLean Neil
Montgomery Michael Andrew
Asman Sanford J.
Hayes John W.
Schlumberger Resource Management Services, Inc.
Trammell James P.
LandOfFree
Modular object-based architecture for extensible master... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Modular object-based architecture for extensible master..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Modular object-based architecture for extensible master... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2945247