JP2004220556A - Distributed subscription service including device model agent and add-on component, method and device enabling automatic supply maintenance and device independent service, low-cost built-in platform in device side and method and device for integrated server platform for executing distributed service and spontaneous provision of device service - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method flexibly supplying improvement of a device after the delivery to a user. <P>SOLUTION: A distributed system 1 allows a recording device 110 and the like to subscribe to and run device-centric services 140. A device model agent 120 allows the device 110 to interact with service host 310 of a service provider 300 to automate supplies maintenance, user help and services subscription. The device model agent 120 can be embedded in the device 110, can be deployed in an add-on component 115 connected to the device 110 or executed by separate machine as a proxy 220. The device model agent 120 provides a run time environment 121 for services 140 available to the device 110 via a common interface along with a common structure. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

  Embodiments relate to electronic copying and recording devices, facsimile machines, scanning devices, multifunction devices, and the like. In particular, embodiments relate to the implementation and distribution of services that such devices can provide to users.

  This application is related to US Provisional Patent Application No. 60 / 319,622, filed October 16, 2002, and 60 / 319,623, 60 / 319,624, 60/60, filed October 17, 2002. Claim priority to 319,624, 60 / 319,625.

  The installation of recording devices and other business devices is only the first step in most of the life cycle of the device. Most devices are involved in an ongoing business process between product owners (users), product manufacturers, and / or third party suppliers. Companies that manufacture recording devices generally have products and services that support the user's documentation and want the user to continue to use and be satisfied with the offering. This post-sale period offers the opportunity to build strong long-term relationships between the manufacturer and the user that are mutually beneficial. This after-sales relationship is not only about what the device does for the user, but also how the device does it, how the manufacturer supports the device, and how the manufacturer It can be defined by how easy it is to handle, own and use the device as a whole. With this understanding, embodiments respond to a user's supplemental needs to receive services that support the device they are using, i.e., in various embodiments, after-sales life cycle, / Repair needs and integrated business processes are addressed. Such processes range from break / repair services (repairs) to the continuous supply of consumables and supplies, product upgrades and expansions, and integration into solutions and other offerings. Traditionally, such post-sale processes are manual in nature and provide the equipment owner / user with an active role in relaying limited information to manufacturers and suppliers when needed. Had requested to act.

  Many electronic copy recorders, facsimile machines, scanners, multifunction devices, and the like provide services that assist users in processes where they must learn how to use or avoid. Also, some devices require annoying meter readings or other types of maintenance. In the case of meter reading, the user may have to read the meter monthly and communicate the results to the supplier, for example, by fax or telephone. In addition, users must manually check supplies of paper, toner, and other materials and order new materials. The number of services provided by the device is confusing to the user, so the user may think that the device is too complex to remember. In addition, to avoid downtime and other inconveniences, users may want to make minor repairs on their own rather than calling for repairs and waiting for service to arrive and repairing their equipment.

  With the advent of modems, users or high-end products at user sites were connected to manufacturers by telephone lines that changed this interaction model. With the advent of widespread Internet connectivity and the proliferation of networked products, new opportunities have emerged that provide a flexible and powerful way to integrate equipment with post-sale business processes. Although network connections solve some of the shortcomings of telephone line connections, the systems presented so far have a number of limitations associated with the interaction model developed for such early systems. There are still.

  The disadvantages of current systems are the tight connection between the communication method and the system architecture, a uniform deployment and integration strategy, and generally no support for already deployed equipment. Systems that provide support for already deployed devices generally have an inconsistency in the handling of already deployed devices and new devices. In addition, the system generally does not include the ability to quickly upgrade, extend, customize and evolve features, processes and workflows, is often limited to basic business processes, and uses external services and solution APIs. It cannot be provided stably. Generally, and almost entirely, the system treats the device as a simple information repository rather than an active participant in the enabled services. The device must continue to enhance its key feature set to remain competitive. For example, in a document system, the properties that are enhanced to increase the competitiveness of the device are typically speed, supply speed, image quality, and document workflow. However, with increasing post-sale interactions between devices, users and suppliers, the ability to incorporate products into solutions and services and vice versa has become a key differentiating device in the marketplace. In the near future, the success and value of equipment will depend on the ability of the equipment to actively participate in the after-sales life cycle, the ability to integrate seamlessly with solution offerings, and the ability to customize and extend based on user needs and requirements. It is likely to be measured. The performance results of such devices are improved, easier to use for the user, the effectiveness of the support provided by the manufacturer is increased, and the overall satisfaction of the user is increased.

  The general trend in the industry in recent years has been to take advantage of the high computing power and connectivity built into recording devices by providing remote services to increase user satisfaction and reduce operating costs. Met. This trend in connected intelligent products began with the realization of remote services on servers and other mission-critical information technology (IT) -related hardware, and has spread to a variety of other industries, including recording devices. . Such a remote service provides valuable planning for both manufacturers and users. When properly implemented, such services allow significant cost savings for the manufacturer and a better after-sales experience for the user.

  This transition is facilitated by several simultaneous factors and needs. Competitive pressures and the need for improved internal business processes will require new ways of interacting with local products and will require relocation of service and support responsibilities. Similarly, manufacturers and users prefer to be able to configure and add new features / services to quickly resolve the problem at hand and quickly deploy new features. The simplification and speeding up of this process extends the lifespan, increases the value of the deployed equipment, and maintains user satisfaction and productivity. Manufacturers must be able to provide such functionality to new and already deployed equipment, but manufacturers cannot be the best in all varieties, and equipment must be third party parts or competitive. Parts that can be easily integrated. One size may not fit all, and there is a need for multiple configurations that provide manufacturers with the ability to configure a solution that suits their individual needs. Also, the manufacturer must be able to make the behavior of the solution consistent across multiple configurations so that it can be managed and supported, thereby keeping the user in control.

  Research focused on determining user preferences and needs for such types of services will ultimately lead to offerings that enhance the way users remain satisfied with recording devices, billing systems and supply chains. He points out the need for new features. This study also shows that users have a strong desire for such services and willing to work with manufacturers to achieve their functions beyond security hurdles. In particular, research has shown that nearly one-third of users are likely to have such remote services adhere to a given device brand upon their next purchase. Most users are willing to pay for the remote service capabilities of their devices, and users have some level of control over shared data, supervised self-healing, automatic software downloads, and As long as you have a particular interest in remote supply / service analysis or forecasting, you will be very or somewhat satisfied by sending data to the service provider over the Internet.

  In addition, analysis of the latest technologies in remote solutions has enabled all major players in the manufacturing of recording equipment and remote solutions markets to provide some degree of remote service functionality and to emphasize that functionality. I understood that. In the offset printing market, embedding remote services in printing presses and peripherals is considered a business cost.

  Services provided to users prior to current systems were assembled and managed end-to-end within a particular product line. This required a product team to invest in developing the infrastructure, services, and back-office connectivity needed to get the job done, not just the product itself. This work was extremely difficult to maintain over time and often overlapped in the product line.

  For example, by simplifying the relationship between the user and a device such as a recording device, the user experience can be greatly enhanced. Embodiments can automate current manual and / or heterogeneous business processes and provide new workflows to respond to user demands. This is achieved, for example, by using an embodiment that allows the device to actively participate in the life cycle and value-added services of the device while retaining the initiative of the user. Embodiments do this using a standard architecture, such as a standard based on a Distributed Management Task Force or a Common Information Model (CIM), and use and / or use embodiments. It allows services to be written once for all devices that are compatible with, making it easy to add new services modularly for each product.

  To achieve these objectives, embodiments provide a common service model, services that operate with multiple disparate devices, and flexibility in physical, logical, and operational configurations. The device plays an active role in providing the user with an enhanced post-sales experience. Embodiments can get seamless integration into both user and manufacturer back-office processes.

  More specifically, embodiments include a flexible end-to-end system for connecting a device to a solution offering. Numerous deployment options in various physical locations and configurations allow the widest equipment coverage and rapid functional deployment for both local equipment and new products, while separating equipment changes from back office changes can do.

  The systems of the embodiments can be reused for all compatible platforms, eliminating the need for individual platforms to reconfigure all back-office systems. Each platform team makes the product available in one of the ways previously described and contemplated by the embodiment, for example by incorporating the embodiment's DMA and / or following a specific service transaction protocol. Just need.

  Agent software components embedded in devices, add-on modules, and device proxies provide an environment in which common device models, common information management (CIM) application programming interfaces (APIs), and device services can operate. provide. The common abstraction of the communication mechanism allows the system to be independent of the physical transport coupling nodes. The service model supports services running near the device and its life cycle, and includes methods and processes for effectively managing and customizing services and solutions. As a result, the service once created in the agent can run on any device, add-on module or proxy including the agent. This allows a system to place devices and device proxies so that they can work together seamlessly from a service perspective, and a backup based on device-based service policies that have inputs from both users and suppliers. Is obtained. The embedded service agent has an active role in the solution offering and works with distributed solutions and / or network accessible servers to provide the required functionality. The server provides a clearinghouse for messages that must traverse the system, and provides the administrative functions needed to connect and customize distributed services at multiple levels of granularity.

  Embodiments can generate economic benefits in addition to high user satisfaction and loyalty. The embodiment can achieve cost reduction by reducing the amount of use of the service technician by the high user self-help function, the remote diagnosis function, and the prediction function. In embodiments that include automatic meter reading, further cost savings can be realized with less collection process infrastructure, better contract enforcement, and less provision for errors. Further, embodiments involving automated supply ordering can reduce inventory, in part, with greater accuracy in tracking consumables at a user site with more timely, accurate, and reasonable measurements. Further cost reduction is realized from the viewpoint that the number of telephone orders and exchanges is reduced and the telephone time is reduced. Finally, embodiments help increase the revenue from new services, as very many users will be willing to pay for the services provided by the embodiments.

  Embodiments respond to user needs and interests, for example, by including new types of remote services. Such services take advantage of the high connectivity of the device in the user environment and utilize the computational capabilities built into the device itself to allow the device to participate in simplifying the user work process. The platform enables a standards-based solution that can be used to modularly and cross-platform remote service offerings that use all of the common back office integration and work processes. Specific examples of the types of services that can be provided in embodiments include automatic meter reading, automatic supply ordering, productivity reporting, software download, user-assisted self-help features, remote diagnostics, and prediction.

  Embodiments provide services and services that exist in devices (printers, scanners, repositories, and other services and solutions) and a life cycle support that facilitates owning, using, supporting, purchasing, and upgrading those devices. Including classes. Market research has shown that such services can increase the value of the device to the user and may increase user satisfaction and satisfaction throughout the life of the product. As a result, this service should increase user loyalty and consideration from the user when making a new purchase.

  Such services, in embodiments, take advantage of new device capabilities, including embedded device intelligence, utilize large numbers of networked populations, survey information technology advances, Enable a more aggressive set of features to be played in the life cycle of the system.

  Embodiments provide a basic set of components and their interconnections that enable suppliers to effectively and efficiently provide such types of post-sales services to users. The high goals defined for the platform have been used to facilitate the architecture and development of early components and services. Each detailed attribute supports the platform's four major goals. All the main components of the system work together behind the scenes to make the offered service behave seamlessly for the user.

  Embodiments provide automatic reporting of meter readings via telephone, fax, or computer network. In addition, embodiments automatically monitor supplies and alert the user when supplies are low, allowing for automatic ordering of supplies in the next and subsequent similar situations. Further, the services provided by the device can be tailored to the specific needs of the user, but can be scaled up or down later as needed by the user with the automated service subscription, download, and installation provided by the embodiments. Can be. Further, embodiments may allow the user to sequence any work the user wants to perform, including minor repairs and replacement of user replaceable units. Yet another advantage of embodiments is the ability to manage the advantages of multiple devices from a central application.

  For a general understanding of the present invention, reference is made to the drawings. In the drawings, like reference numerals have been used throughout to designate identical elements.

  Embodiments provide a system 1 of several types of distributed software and hardware components that guarantees the flexibility and responsibility of component physical and logical system design. Embodiments include, for example, a device 110 in a user / user environment 100, an asset management system 200 that can be in a user's network or environment 100, and a service host 310 that provides services 320 to which the device can subscribe. Use the included architecture. System management and services are provided to the system, where the device is actively involved in both the service and life cycle needs of the device itself, as well as only a portion of such services and life cycle.

  Using Device Model Task Force (DMTF) Common Information Model (CIM) as the basis for service management, Common Device Model Agent (CDMA) In addition to 120 active behaviors. See, for example, FIGS. 1 and 10 for details. Each device 110 services the status and configuration of the device 110 (part 111), the services 140 provided, and other information (eg, additional part 111) using a common intermediate language such as DMTF CIM. • It is preferably presented to the service host 310 by the CDMA 120 communicating to the host 310. DMA also provides the service environment 124, which is the runtime environment of the service 140, on the device where the service 140 resides, and provides device independence of the service provided by the service host 310. Thus, a particular service 140 can be written and executed once on various devices 110. This allows a one-to-many configuration to be available, requested, and utilized as needed. For example, embodiments may include device proxies, including simple proxies that include only behavior, and proxy device models, as described in further detail below. Embodiments may also include devices that communicate directly with the service host.

  The CDMA 120 includes a service environment 124, a CIM API 123, a CIMOM 125 and a service manager 126 in the core DMA 122, and a common provider API 121. The common provider API 121 communicates with the device-specific provider API 112 of the device 110 to retrieve information 111 about the device, including, for example, its configuration, status, and supply level. Next, the common provider API 121 makes such information available to the CIMOM 125, the service manager 126 in the core DMA 122, and the service 140 running in the service environment 124. Thus, in embodiments, the DMA 120 may reside between the service layer 141 (the aggregation that performs the service 140) and the device-specific API 112 and may communicate directly with the service host 310. In such a case, the DMA 120 must be connected to a communication medium, such as a telephone line or computer network, to be able to communicate with the service host 310.

  Partly due to the result of using DMA 120, system 1 of the embodiment achieves substantial communication medium independence. The device 110 communicates with the service host 310 and / or service proxy via a network, landline, cellular, packet radio, pager, Bluetooth ™, IEEE 802.11, or other suitable communication method. can do. Such communications may be made from the device or from the host, monitored and / or audited, and may reflect user preferences, service offerings, and overall quality of service. Can be used to determine which choice is appropriate for a particular scenario. The service 140 can be independent of the device configuration, the back office or supplier 300 can provide details of the service content, the service subscription is issued and activated by the back office business process, and the new service Can be quickly introduced.

  Thus, embodiments include an end-to-end system 1 assembled from many components using a unique combination of modularity, distributed computing, service models and transactions. Embodiments use a modular overall system architecture that supports fast and flexible service deployment. This architecture is advantageous because it uses the functionality and identity abstraction of the messaging model for system elements, common interfaces, and communication between them. The device service has four main entities that work together in a consistent and flexible manner, which entities specialize in the device itself, management and service applications in the user's environment, service management and service configuration. A back office server, and a business process integration server and business processes surrounding such services.

  FIG. 10 is a schematic diagram of main components that can constitute the platform presented according to the embodiment. An intelligent agent 122 coupled to the small footprint embedded platform 140 as well as the DMA 120 can be located and integrated with the device 110. The intelligent proxy of device 110 allows for group management and participation in services and may be included in the platform as a standalone application or as part of another application. Further, such intelligent proxies may enable legacy devices that have not yet been enabled to connect with aspects of the embodiments. A media-independent communication and application infrastructure connected to computer and other communication networks that can securely and robustly connect local equipment and products to the supplier and its internal systems, such as the Internet and the supplier intranet. Structure is used. In addition, embodiments include a set of industry-standard web services technologies integrated with value-added extensions to enable such services. Thus, embodiments provide a set of services running on an end-to-end system supporting the device.

  The devices 110 are generally physically located at the user site 100, but embodiments may accommodate devices 110 at other sites and may be distributed worldwide. Various devices 110 can be included, ranging from low-end products to high-end systems. Embodiments use an apparatus 110 that provides, for example, three major enablers in this system. The device 110 uses a Common Device Interface (CDI) and a Common Information Model to enable easier integration with services by hiding device specific differences behind the interface. ) (CIM) 123 is provided. The CDI can be realized in the CDMA 120 as a common provider API 121. This allows for the reuse of services and greatly reduces the complexity of the system 1. The CDI is specified by the Distributed Management Task Force (DMTF) CIM for service and service management, with service provider and / or manufacturer specific extensions. Also, CIM 123 may be compliant with DMTF CIM with certain extensions suitable for devices with services that can be provided by service providers and / or manufacturers, including diagnostic extensions.

  The device 110 in an embodiment of the inventive system 1 provides, for example, an embedded platform 124 that can send services 140 to the device 110 and execute near the device 110. The embedded service platform 140 also provides local service management via the service manager 126 and the ability to accept newly deployed services 140 out of sync with the hosting platform software release. This reduces system complexity and speeds the on-site deployment of new or sophisticated services. In embodiments, the DMA 120 provides the embedded platform 124, but preferably other systems can also provide the platform. The DMA is preferably a software module that allows access and use of the device's built-in computing power, data, and functions in a co-located service.

  These components are typically distributed throughout the user's environment 100 as well as the supplier 300. At the same time, these components provide a flexible end-to-end system 1 for connecting products (such as devices 110 and services 140) to post-sale solution offerings (additional services 140). The system 1 is, in embodiments, designed to provide an architecture that supports a range of deployment options at various physical locations and configurations. Embodiments preferably provide the widest device coverage and the fastest deployment of features to local devices and new products so that changes in device 110 are separated from changes in back office 300. Embodiments further provide a unique value-added agent software component DMA 120, add-on module 115, and / or common device model 122, DMTF CIM API 123, and new device service environment 124 that are incorporated into device 110. Device proxy 210 is provided. Further, embodiments can provide a common abstraction of a communication mechanism that can make the system independent of any physical transport (between the device and the supplier system) that connects the nodes, thereby providing user requirements. Based on the above, higher flexibility and arrangement customizability are realized. The service model of the embodiments supports services running "near the device" and the life cycle of the device, including methods and processes for effectively managing and customizing services and solutions. The services in the embodiments described above with respect to DMA 120 may operate on any such enabled device 110 or proxy 220, and seamlessly arrange devices and device proxies from one another from a service perspective. Can be operated. The response in an embodiment can be achieved with a device-based service policy based on information provided by both the user and the supplier, and can enable the service quickly.

  The DMA 120 of the embodiment has an active role in the solution offering and works in conjunction with the distributed solution. Such a distributed device agent 120 operates with a server 310 at a supplier 300 accessible via a network such as the Internet or a telephone system. The role of the server is to provide a clearinghouse for messages that must traverse the solution, and to provide the administrative functions needed to connect and customize distributed services at multiple levels of granularity.

  For an already deployed device 110 that does not have this feature, an option to add the physical system component 115 to the device 110 internally or externally enables this feature and is provided by embodiments. For the inventive system 1, the device 110 enabled in this manner is no different from the device 110 with built-in functionality, as long as the add-on component 115 has a good interface to the device 110. Looks like. For example, an embodiment including such an add-on component 115 may be attached to an input / output terminal (IOT) of a recording device, connected to the IOT via an EPSV, PWS, and possibly a CAN bus interface, and connected to a network. Components can be provided. This configuration gives the IOT the functionality involved in device services 140. This add-on component 115 then has to access the non-standard or network-inaccessible APIs to provide DMA and service platform with full-range device functionality, so that this one-on-one Can be found in the mapping of

  To address the fact that the input / output terminal (IOT) may be from another manufacturer and the user can select from a large number of digital front ends (DFEs), the embodiment uses an add-on system. Features components. This add-on component may be, for example, an operating system such as Linux or Darwin, or a low cost running a Java virtual machine such as Insignia's Jeode® Embedded Virtual Machine running a DMA service platform, for example. Embedded personal computer platform. This add-on component can be directly connected to the IOT via an interface such as EPSV or PWS. Next, the device is connected to the user's internal network.

  The device management and service application 220 at the back office server in the user environment is specialized for service management and service configuration business process integration servers and business processes around such services. A schematic diagram of such system level components and their interconnections is shown in FIG.

  Embodiments relate specifically to the role of the device in providing services to users in end-to-end system management and post-sale application architecture. The present invention focuses primarily on the Device Model Agent (DMA) 120, a device-side technology module in a Device Centric Service (DCS) platform. DMA is a thin and efficient application / service execution environment. DMA provides a flexible, extensible, and dynamic service management system that allows online services (e-services) to be designed, added, and managed in the system without modifying the platform itself. . Although the present invention specifically shows the integration of benefits from DMA to document system equipment, this concept is equally applicable to other fields. The DMA runtime environment is a thin software interface layer on the document system device between the Java runtime environment and the embedded web server.

  The device model agent described herein adds the following functions to the document system device. The unique combination of these features allows for several benefits associated with developing, deploying, and maintaining systems management applications.

  DMA 120 enables active involvement in applications and service offerings, such as, for example, post-sales services, system management services, and other services. Devices 110 incorporating DMA 120 may perform some computing tasks required by system management applications and services. In this architecture, for example, the application server 200 or the back office server 310 of the supplier 300 installed in the user environment 100 and the target device 110 cooperate to complete the system management offering. As shown, for example, in FIGS. 10, 13 and 14, the DMA 120 provides a service execution environment 124, where the service 140 is a system running on the application server or host system 310 of the service provider 300. It can operate as a management application or the host system 320 in whole or in part.

  The DMA service is preferably capable of monitoring device events and taking prescribed actions. The DMA 120 preferably can publish data to the subscriber / user when an event of interest occurs, and can invoke methods such as diagnostic routines on the device 110 when directed by an internal or external client or user. Preferably it is possible. This moves device-specific processing from the central application server 320 closer to the device 110. The role of the application server 320 is to translate from the computing platform for the execution of the application / service 140 to the management and configuration of the application / service 140. Thus, device 110 actively participates in the process symmetrically with a passive data repository in a strict client / server architecture.

  Also, the DMA 120 according to the embodiment can perform a dynamic update of the service 140 and support components operating within the end-to-end DCS platform 1. Devices 110 that use DMA 120 can dynamically add new service components 140. This allows a user or application component already on the device 110 to request such an addition to support the service 140. This also allows components to be added and deleted as needed without recompiling or restarting the system or DMA. In embodiments, the target device 110 itself begins to add new or upgraded services in its entirety or to support components of existing services. This allows the device 110 in the system 1 shown herein to be responsible for initiating activities to maintain itself and the system management services running on it.

  Embodiments further recognize the need for an application / service execution environment 124 that allows developers to work with a consistent and standards-based set of tools. DMA 120 enables the development of device-independent after-sales applications 140. Applications 140 created using the DMA 120 interface do not need to be modified to accommodate new or upgraded DMA enabled devices. DMA 120 implements the model-based approach adopted by DMTF to achieve application / service device independence, but adds a new component to this implementation, called service manager 126. The service manager 126 is primarily responsible for controlling the service 140 life cycle of each service 140 activated for the device. Further, for control and management of the service 140, the service manager 126 preferably manages the service 140 and provides a programmatic interface (API) to a local or remote system management client.

  In operation within the end-to-end DCS platform 1, the DMA-capable device and the DCS application server may be accessed by the application server or host system 320 on the service host 310 of the supplier 300 or by a third-party service provider. Enables service response and management. The DMA-capable device 110 and the application server 320 cooperate to implement dynamic coping. Using this system, a user can survey a set of applications, select or customize one or more applications to meet the needs of the user, and order the selected set of applications. Subsequently, the application can be installed, enabled, launched, monitored, and / or managed.

  To cover the standards of new and existing devices, the architecture of the DMA 120 in the embodiments allows for deployment in several ways. According to the embodiments as shown in FIGS. 4, 9 and 11, for example, the DMA 120 is incorporated in the network connection device 110 such as a printer or a multi-function device. In this embodiment, the DMA 120 is a component on the web server side. DMA 120 can use standard methods, such as Java servlets, for example, to host service components behind a web server.

  Alternatively, DMA 120 can be incorporated into dedicated hardware devices or add-on components 115 of stand-alone devices 110 such as copiers or existing devices in the field that cannot run DMA 120. Such an add-on component 115 is schematically illustrated in FIGS. 12, 16 and 17 and will be discussed in more detail later.

  Another alternative is to incorporate the DMA 120 into the network application 220 as a single device proxy configuration or multiple device proxy configurations. Such proxy configurations are illustrated, for example, in FIGS. 7, 8 and 11.

  For any device manufacturer, the after-sales application may be important to maintain user loyalty. For suppliers of recording devices and / or multi-function devices, selling a document system device is just the beginning of a relationship with a user. Ongoing service, support, supply and sustained maintenance are key considerations in determining user retention. However, as mentioned earlier, cost-effective development, deployment, and management of post-sale applications themselves pose some challenges. Complexity is increased by the presence of multiple stakeholders, including developers, device manufacturers, service owners, and customers / users. As a platform, the DMA 120 is preferably designed, according to an embodiment, to organize all key stakeholders and to address the requirements of all stakeholders.

  The DMA 120 preferably forms an abstraction layer between the device-specific interface 111 and the system management application. See, for example, FIGS. 10, 13 and 14. Abstractions provide a common view of device data, events, and operations to system management applications. DMA 120 performs device abstraction using a model-based approach. The equipment model used for this is based on industry standard activities in the DMTF (Distributed Management Task Force) Consortium. As a basis, the enhanced DMTF Common Information Model (CIM) is used. However, the implementation of the common model by the device interface is unique. The interaction between the post-sale application client and DMA is based on the DMTF CIM Operations Over HTTP specification.

  DMA 120 enhances DMTF / CIM implementation by adding service manager component 126. The service manager 126 is responsible for loading the service 140, maintaining a list of the services 140 currently installed in the DMA 120, and maintaining the management and life cycle control of the service 140. The service manager 126 preferably operates as an automated process, and can automatically reference and initiate the service 140 as a separate component that can be accessed programmatically or with the DMTFCIM API 123. Service manager 126 may provide access to active services 140 on device 110 as well as management data for one or more active services 140.

  DMA service manager 126 preferably supports core services that are automatically started when service manager 126 loads. Preferably, such core services do not require response support. In addition, the service manager 126 preferably supports a defined service 140 that requires implementation by the dynamic support function of the DMA 120.

  FIG. 15 is a schematic flowchart illustrating the activation and normal execution of the service manager 126. Upon activation, the DMA 120 starts the service manager (block 510). Next, the service manager 126 loads the core service (block 511) and queries the dynamic service capable host (block 512). The service manager 126 further interprets and processes the service configuration parameters (block 513) and loads and starts the specified service 140 (block 514). Next, the service manager 126 monitors the service 140 for management (block 515) and interacts with the system management client as needed (block 516).

  The DMA 120 is preferably created using a substantially platform independent language, such as Sun's Java 2 Micro Edition (J2ME). Therefore, DMA is extremely portable and can be used as a system component in any system configuration where Java is available.

  The management and service application 200 according to an embodiment can be deployed in a user's environment. Some applications 220 include services of the device 110 that are networked but not fully enabled to actively participate in device services themselves, for example, as schematically illustrated in FIG. By partially acting as a proxy, provision of device services can be enabled. In other words, the application 220 can act as a proxy for a networked device that does not have software that directly supports the DMA 120 or the service offering 140. For example, some applications, such as Xerox®'s CentreWare Web (CWW), can serve as a device proxy for Simple Network Management Protocol (SNMP) enabled devices. This can be a good way to make a device a layer of service, in that the SNMP agent in the device provides the necessary data and functionality to support the service being offered. In such a case, an application, such as CWW, is responsible for hosting the service 140 running near the device 110.

  For the back office or host portion 300 of the end-to-end system 1, such as the service host 310, the device 110, when proxied by the application 220, is almost the same as if the device communicated directly with the service host 310. looks like. The differences between the proxy device and the direct device are not as substantial as those associated with the direct device having different levels of firmware. Differences in device capabilities can be managed on the backend / service host 310 by a device based service enabled system. The effect of such a difference is that advanced services that make use of the very specific features of a given device are almost non-portable, ie, services created for the product-specific part of the CIM extension. May be completely non-portable and incompatible with other devices. However, services created in the core and common models remain portable, and placement issues are managed by the response system.

  The application 220 can also act as a service proxy for devices that are not directly networked but have the add-on connection option. Such a connection option may be hardwired, such as Ethernet (registered trademark), or wireless, such as Bluetooth (registered trademark) or IEEE802.11, and its effective range may be local or wide. For example, an independent copier that is not networked for printing will have a small wireless LAN connection, such as 802.11b or another wireless network. A proxy behaves exactly as a network-connected device without DMA is represented, but a proxy is required for wireless access points used to communicate with devices with add-on connectivity Hardware. An example of such a system is a CWW installed on a server that is physically networked over a LAN and has an added wireless access point. For the back-office edge host 310, the wirelessly delegated device 110 appears to be no different from the delegated device on the LAN.

  The application 220 also allows services to be managed together from servers in the user environment. In embodiments, the device proxy may provide aggregation and group management functions for services associated with the proxy device. This is, for example, a graphical user interface (GUI) where a system administrator or user checks the status of services on a set of devices.

  The common device interface for services and their transactions to a back-office system such as service host 310 may be an extension of the interface used on the device itself. This allows the service to operate both in situations where the device is direct and where the device uses a proxy. APIs from devices that communicate directly with the service host are supported, along with a limited set of specific device proxy extensions that handle transactions and data associated with the proxy. All transactions directed to the device must look the same.

  With reference to FIG. 2, additional parts of the exemplary embodiment are shown. The host portion of the service, service host 310, may be outside of user sites 100, 200, and may be at the manufacturer's or other service provider's facility 300. The device service edge host 410 handles transaction and service management for device services located on site. This includes the management of message queues supporting the distributed services 140 and the correspondence of software modules and configuration parameters. The edge host 410 also serves as a security host end and service model used by the device service system 1.

  Edge host 410 also provides a connection to service sponsor system 310. This connects the external device services world to the internal (or third party) services world. The connectivity of each organization that sponsors the service is maintained by the edge server and can follow the security rules and rules of the entity that maintains the server and host. The edge host eliminates the need for device 110 or device proxy 220 to have direct knowledge of the details of the service contained on service host 310 interacting with the back-office aggregate. This is advantageous when deploying device services in a manageable and robust manner. Embodiments preferably provide a common service API to the back office sponsoring organization to standardize basic operations. Certain services can extend and customize the content of the transaction for a given application.

  With continued reference to FIG. 2, the device 110 and a user application 220, such as a CWW, can be deployed in the user's environment 100,200. This may be a managed service environment or a normal user environment. Services and communications are distributed and interconnected from the user's internal systems and networks 100, 200 across the Internet and other suitable long distance connections 400. Known and future web services are preferably used between the devices / applications 110 and 220 and the edge host 410 and between the edge host 410 and the internal service provider 310. 130, 230, and 330. System 1 must be configured to meet basic IT industry and other standards due to its ability to work with existing firewalls on both the user side (firewall 160) and the service provider side (firewall 360). Is preferred. No special configuration of the user's firewall 160 is required for this system to operate properly.

  The service delivery system 300 is preferably part of a basic supplier infrastructure that provides a robust and well-managed 24x7 level of service and disaster recovery used by all user systems. As previously indicated, the edge host 410 can handle transaction and service management for device services located on site. This includes managing message queues to support distributed services and mapping software modules and configuration parameters. It also serves as the host end of the security and service model used by the device service system. In embodiments, the edge host also connects the external device service world to the internal (or third party) service world. The connection to each organization that sponsors the service is maintained by the edge server and preferably follows the security rules and regulations of the supplier.

  In an embodiment, the edge host 410 allows the device or device proxy to not have direct knowledge of the details of the included service's interaction with the back office collection. This can help manage and robustly deploy device services. To standardize the basic operations, a common service API is provided to the back office sponsor organization. Certain services can extend and customize the content of transactions for a given application.

"Multiple transmission path"
At the highest level, the system 1 is designed such that the service 140 operates directly between the device 110 and the back office (supplier) 300, or with the assistance of the device proxy 220, depending on the system. This allows the device proxy 220 to service a large number of legacy devices very quickly while the user is slowly acquiring new devices to be directly enabled, so that the widest possible deployment is possible. Done quickly. It is also important to have both modes of operation, as some users prefer the proxy to behave as a consolidator / cleaning house for messages leaving the site rather than from each device individually. . At other sites, the user may not want to install a device proxy, and thus need to enable the service directly. Finally, besides making each path available, it is beneficial to have the services work together, since the user can perform both scenarios simultaneously.

  It is beneficial to make such paths invisible from the service provider's point of view, so that multiple paths can increase deployment flexibility. Embodiments preferably separate the device 110 and the proxy 220 from the back office system 310 as much as possible. These two powerful abstractions and separations allow the functions within the device 110 or the back office 300 to be arranged independently in a stepwise fashion. Furthermore, if a change in the system at either end needs to be made, the change does not affect the entire system 1 if the appropriate abstraction is enabled, enhancing the integrity.

  Referring again to FIG. 10, the overall abstraction of the embodiment includes an abstract device model 122 embedded in the DMA 120 at the device level. The abstract device model 122 is preferably configured using the DMTF CIM as a basis. In an embodiment, device model 122 and platform 124 are both in DMA 120. The common service specifies the supplier's domain 300 regardless of the service offered. Also, at the back office / supplier level 300, embodiments use a common API for service sponsors to build and manage services from the supplier back office 300. The common API treats the device 110 the same, regardless of type or connection mechanism.

  This architecture in an embodiment provides flexible deployment options, such as deployment flexibility, in terms of device communication directly to the supplier or via a proxy. In addition to flexibility, the service itself can be defined such that its many parameters can be customized. This service customization includes, for example, data sent as part of a remote monitoring service, and the time or frequency at which meter readings are sent to the supplier. The exact configuration parameters may be specific to the service provided.

  The platform of the embodiment is designed so that the configuration of the service can be easily managed. This system allows the configuration of services to be specified by individual device serial numbers for all devices at the user site or for all devices owned by the user regardless of location. In embodiments, this management is performed at the back office controlled by the service provider.

  Yet another part of the flexible deployment option is to use subscription criteria for services available to the device, according to an embodiment, as schematically illustrated in FIG. The subscription process can be controlled and managed, for example, by an individual service provider, and the services presented on any given device can be controlled by a combination of user wishes and service provider authentication. . Thus, not all devices must provide or install the same service at all times, even in the same product line.

  There are several activities associated with DCS. For example, Axeda, Embrace Networks, Questra, and Imaging Portals have been effective in terms of service. An example of these technical embodiments is Embrace Networks Patent Application Pre-Grant Publication No. 2002-0133581 A1, which is incorporated herein by reference. However, the prior art has no correspondence mode and does not seem to have important support for the correspondence.

  Several companies, such as 4th pass, sell general purpose software, but none of the prior art is expected to encompass aspects of the present invention. For reference, Sun has a general list of such supported software at http://java.sun.com/j2ee/provisioning/industry.html. In addition, all companies are likely to target the mobile phone industry as their target market.

  As mentioned above, wide area telecommunications companies are beginning to offer services on mobile phones. To achieve this, all mobile phones use the Java standard called CLDC. This released standard specifies how Java programs can run on small devices such as mobile phones, or more importantly, a modular program called Middlets that, at runtime, is implemented in the CLDC Java environment. It specifies how it can be added.

  This standard defines the corresponding units and how they are accepted and installed on the device side, but makes no mention of server aspects. To do this, the telecommunications companies either created their own compliant server solutions or purchased from compliant vendors listed above. Due to the highly competitive environment in this area, there is no way to test for alternative solutions.

  The second related standard is called OSGi. OSGi is a Java-based release standard that allows devices connected to a local network to communicate with a remote server to download and execute modular services. This standard has received less industry support than CLDC / Midlets. OSGi also avoids server side issues of response.

  The third standard is SyncML Device Management. SyncML is a release standard that focuses on the details of synchronizing mobile devices with several server-based sources. The aim of this standard is something like a calendar or a promise. Last year, the synchronization protocol was extended by device management efforts to explicitly change service settings on a mobile device and allow services to be downloaded to the mobile device. SynchML avoids server-side compliance issues.

  The last standard, without a name, is commonly referred to as JSR-124. In short, Java programmers use the Java Community Process (JCP) to create and standardize Java Specification Requests (JSRs) as additions and extensions to the Java language. JSR-124 is a J2EE Client Provisioning Specification. J2EE is a standard for using Java in high-end transaction processing. The markets around this have grown significantly. In fact, JSR-124 seeks to define a framework that represents a corresponding system. Almost all corresponding start-ups and telecommunications companies are members of JSP. This ensures that all compliant systems are generic enough to be able to interact with the J2EE system in all standard ways, and so loose that vendors can create alternative competitive solutions. The standard is being published and the draft is being evaluated.

  Embodiments include defining and implementing a common correspondence model based on a shared user service life cycle. The Provisioning Server (PS) 310, the DCS device 110 talking to the PS, and the supplier interacting with the DSC device preferably operate according to a shared model of how the corresponding process operates. A life cycle model that defines roles and responsibilities can be created for each stakeholder interacting with the PS 310. Based on roles and responsibilities, grammar and commands have been developed to enable stakeholders to achieve their role-based goals.

  For example, the architecture and implementation of a corresponding server 900 running on a service host 310 that meets all the requirements of this section is schematically illustrated, for example, in Table 1 and FIG. Going from left to right in FIG. 20, the first major module is the service customer interface 901. This is preferably responsible for all interactions between external user 110 and external device 220. It is also desirable to separate other PS modules from the device and the various protocols that the customer may use. The preferred protocol in embodiments is web services, but in the future it can be extended to http, email, mobile phones and other transmission formats. For an incoming transaction, send the transaction to the appropriate internal resource to service the request. In the case of an outgoing transaction, it takes the output of another PS module queued for the device or user and translates it into the necessary protocol to interact with the device or customer.

  Entity management module 902 is a general purpose PS resource that preferably localizes entity information and separates it from other parts of server 900. This module holds information about entities, such as devices, users, their preferences, and associated location information. For non-local entity information, the entity management module 902 is one point of contact with such other IM systems. Module 902 provides a seamless interface to local and network based information.

  The order processing module (OPM) 903 is responsible for directing the processing of orders from service sponsors and created by the policy and preferences module (PPM) 904. OPM 903 interacts with the PS module needed to fulfill order requirements. OPM 903 also preferably tracks the status of the order so that it can respond to queries from sponsors.

  A registration, authentication, & authorization module (RAAM) 905 is responsible for maintaining the security of the system at all times. RAAM 905 preferably authorizes all users of the PS to allow them to perform certain transactions. Has the role of properly registering all internal and external users. RAAM 905 does this by working with entity module 902 to obtain the required information. RAAM 905 also preferably has a role to work with service customer module 901 and order processing module 903 to isolate artifacts related to transaction security.

  The service definition module 906 has a role of maintaining all definition information on all services 140 provided from the PS 900. Examples of information included are version information, file structure, service relationships, and product line support.

  The service developer interface module 907 is responsible for assisting service developers in developing, distributing, and updating services. The service participant interface module 908 is responsible for interacting with all users to direct service life cycle and service transaction information to the appropriate resources.

  Embodiments flexibly model, develop and inspect service policies using software computing techniques such as rules and constraints as common solutions. Overall, the response decision itself is less important. That is, in the case of the device 110 requiring the service 140, the PS 900 determines whether or not the bundle is compatible with the operation parameter information (model type, OS version, and the like) of the device 110 (ie, configures the service to be installed). To determine if there are multiple bundles, which one to select if there are multiple bundles, and what the parameter settings (if any) for the service 140 must be. Generally, in embodiments, it is not possible to create code that implements "business rules" that can be used to solve the above problems. Coding is required for each rule change, and the rules are not examined directly by the policy author, assuming that each issue is separable from the others. Further assume that there is one policy creator that determines the answers to all the above questions. Thus, in embodiments, alternative solutions must and should be provided.

  Advantageous benefits are provided by the introduction of appropriate constraints or rules systems. Coding is greatly reduced when "rules" are entered at a higher level of abstraction. In addition, the rules can be examined by policy creators who are not satisfied with the computer or programming. Further, knowledge realized as constraints and rules relating to each problem can be easily combined without having to worry about separability. The constraints and rules support the existence of a number of policy authors involved in the conclusion of the above problem. Interference with rules and constraints based on the various groups involved in the value chain can be more easily identified and resolved.

  In some situations, the ability of the correspondence server 900 to identify the correct bundle and parameters using policy-based knowledge may be advantageous. For example, this capability is preferably applied when the PS 900 receives an additional service request and needs to calculate the answer to the aforementioned problem. In addition, PS 900 uses this capability when the policy creator of any service updates policy knowledge. The PS 900 can calculate the impact of changes, additions, or deletions to existing associated devices that are actively connected to the PS 900. The PS 900 may then generate the necessary change requests to the affected device 110 to achieve the change objectives, and use any future additional service transaction changes. When the PS 900 is notified of the configuration change from the device 110, the PS 900 determines whether the service 140 and / or parameters of the device must be changed for the change. If necessary, the PS 900 can generate a change request for the device 110 in response to a request from policy knowledge.

  The use of rules allows policy setters to define uniform service versions or parameter settings based on internal or external customer requirements. This uniformity can be defined at the user level, site level, device category, or other relevant group.

  In summary, the service subscription and deployment method includes identifying a target service offering 140 by a user or user DMA 120 and requesting activation of such services (block 501). During planned confirmation by the edge host, or during a special connection for that purpose, DMA 120 sends a message to supplier system 300 regarding the target and the requested activation. The supplier system 300 retrieves the message from the edge host 410 and applies business rules and work processes to determine user eligibility (block 502). If the user is approved, the supplier system 300 notifies the edge host 410 that the requested service 140 can be added (block 503). Next, DMA 120 contacts edge host 410 and receives a message that service 140 can be added (block 504). Next, the DMA 120 activates the service 140 and downloads and / or installs the service as needed (block 505). Next, a new service is deployed and operates (block 506).

  Services can be sold on multiple channels. This process is preferably owned by the sponsoring organization (service provider) and is performed in a manner selected by the sponsoring organization. This can be done, for example, from the device as needed.

  After the sponsoring organization is notified that a particular user wants to enable a service on a given device, embodiments provide a business rule that the sponsoring organization must follow a business model that is reasonable for the particular service. And apply the invoicing / delivery process. If the sponsoring organization determines that the device can be authorized to provide the specified service to the user, the sponsoring organization will formally place an order using the common service order / entry API on the edge server. This can, in embodiments, generate a message that can initiate the deployment and configuration of the desired service.

  The message is preferably queued for sending, and the process waits until the message is sent. After the requesting device or device proxy obtains the order message, the system is configured, additional software is downloaded as needed, and new services are started. Preferably, the service sponsor can be turned on and off as needed by the system according to the embodiment based on what criteria the service sponsor determines. The service is preferably created in a device-independent manner. The common information model provided by the device model agent, in embodiments, provides device independent devices for common data and methods. The service is configurable because not all users have the same requirements. Configurable services make it possible to adapt to changing requirements and operations that may be required. Services can be dynamically loaded so that new services can be quickly deployed to users by devices already deployed at the site. Services also have a life cycle that allows management after they are initially deployed. Examples of life cycle transactions include, but are not limited to, adding services, deleting services, modifying services, synchronizing services, device registration, and proxy registration.

  In an embodiment, the DMA 120 is defined to allow the co-located service 140 to access and use the embedded computing power, data, and functions of the device 110. With the embedded agent 122 and service platform 124, embodiments can support local operation of services 140 that enter the entire system 1. This provides common connectivity, service managers, common data access and methods, and reliable communication to service providers / suppliers in support of service offerings.

  For the systems, components, methods and embodiments described above, there are several ways in which the system can be deployed. The flexibility of this arrangement is a major advantage of this system and is closely related to the detailed design of the components and the behavioral models that the system follows. Embodiments with defined abstraction and modularity allow all such placement options to be instantiated at the same time. In many user devices, it is possible to arrange multiple options to guarantee full coverage. 4 to 9 and 11 show some exemplary embodiments representing possible deployment options of the system according to the invention.

  Configuration A of the exemplary embodiment shown in FIG. 4 is a preferred embodiment of a smart device currently shipping from several companies, such as Xerox®. This can limit the amount of infrastructure required by the user to support the deployment of service 140, and provides the simplest implementation. Although no additional hardware or software needs to be installed in the user's environment, the device 110 must have the functionality of the DMA 120, including the service platform 124. This embodiment can hardly accommodate the large number of devices already on site unless the device software is upgraded or another method is used to provide the devices on site with a DMA and service platform. Although the communication between the device and the back-office host via DMA is substantially independent of the physical media, the preferred embodiment uses the user's network and the user's Internet access to provide Connect to the vendor's host system. Of course, other communication schemes may be used, such as, for example, local radio, long distance radio, telephone, radiotelephone, satellite telephone.

  As shown in FIG. 4, each device 110 includes its own DMA 120 and performs its own service 140 in its own service layer 141 facilitated by the DMA 120. The management and other applications 220 may be used on another device 200, which may be in the user's environment 100 or elsewhere. The device 110 preferably communicates with the supplier 300 and the service host 310 therein using a web service 250 such as HTTP, HTTPS, SOAP, or the like. Service host 310 includes service 320 and a host system 340 that can evaluate communications from DMA 120 and deploy service 140 at appropriate times.

  Arrangement B of another exemplary embodiment shown in FIG. 5 allows devices already in the field and third-party devices that do not incorporate the required technology to support device services. Although multiple devices can be processed as such, this description will focus on one such device for simplicity. In this case, a relatively small add-on component 115 is added to the device 110. The add-on component 115 includes software and DMA 120 necessary to enable the add-on component 115 to access internal data and functions of the device 110 and one or more connections to the device 110. When the add-on device 115 is connected, the device / add-on component combination is fully usable from the service infrastructure and other parts of the back office system, as in the configuration A shown in FIG. Looks like a device. This provides equipment services according to embodiments of legacy and third party manufacturing facilities. In this case, the add-on component 115 communicates with the supplier 300 via the web service 250 via the DMA 120 and its associated service environment 124, as in deployment A of FIG.

  The arrangement C of the third exemplary embodiment shown in FIG. 6 uses a proxy configuration in which the application 220 can act as a proxy for performing the services of at least some of the devices 110. The device 110 without the necessary software success factors incorporates the DMA 120, platform 124, and the like. However, the application 220 acting as a service proxy for the device can communicate with the device 110, such as, for example, a LAN, telephone, wireless, or other communication medium. The underlying proxy implements the service API 140 of the selected set of services 140, but preferably does not use the full DMA 120 and standard dynamic service placement methods on the device 110 itself, as such This is because legacy functions cannot be supported by legacy devices. This arrangement is also limited by the richness of the connection between the simple proxy and the device, and if data or functions cannot be accessed remotely, services that require them cannot be deployed.

  Arrangement D of the fourth exemplary embodiment shown in FIG. 7 is a more advantageous form of the proxy configuration. This embodiment enables the device to be used without the necessary embedded software success factors (ie, DMA 120), but communicates in other ways, such as, for example, a LAN, telephone, wireless, etc., to participate in the service deployment system. be able to. Device 110 communicates with one or more applications 220 that act as a service proxy for device 110. The service proxy is a DMA-enabled proxy that can host the DMA 120 of each device 110 that communicates with the service proxy. In addition, the service proxy can manage the DMA 120 of the communicating device 110. This allows the service 140 to operate on the service proxy in exactly the same way as if the service 140 were running directly on the device 110 itself. This also allows additional local applications to be created on the service proxy that can take advantage of the DMA 120 and a common information model representation of the data and functions of each system. This can greatly simplify the application because the application can be hidden from implementations specific to each device and only needs to be configured into a common representation of data and methods in the CIM. . This is the same advantage that services gain when created for CIM and DMA. Further, the portion of the DMA that can manage multiple instances of the CIM and services can be instantiated once and used to manage the DMA proxy for multiple devices. That is, there is no need to duplicate the full DMA for all proxied devices, which makes this embodiment more efficient than simply dropping all DMAs of connected devices onto one server .

  Another aspect of an embodiment of a service proxy is that a portion of the DMA that can manage multiple instances of the CIM and the service can be instantiated and used to manage the DMA proxy of multiple devices. is there. Thus, it is not necessary to duplicate the complete DMA for all proxied devices, but rather one DMA can be used for multiple devices. This increases the efficiency of the arrangement rather than simply dropping one DMA for each device on one server.

  In particular versions of arrangements C and D, embodiments cover arrangements of device proxies for printers connected directly to personal computers. The proxy can be hosted on the user's computer, and the device with which the proxy interacts is a printer, such as a printer connected via a parallel interface. In embodiments, the proxy may also connect to the print driver of a directly connected printer as an additional source of data that implements a DMA or service interface. In that a computer can host a DMA and be supported by a local device via a direct connection to the device and a print driver or other access mechanism, then the directly connected printer is a service and system management perspective. Seems to be networked from.

  The arrangement E of the fifth exemplary embodiment shown in FIG. 8 includes a modification of a part of the exemplary embodiment shown in FIGS. 6 and 7. Services can be provided locally, i.e., within a substantially self-contained site, in a manner similar to embodiments spread over the Internet. Such embodiments enable implementations that use the DMA 120 abstraction to provide more consistent management and services to the local device 110. It has no connection to the back office service provider 300, but the service 140 may be user specific or simply self-contained for security. In this case, management of local services 140 and devices 110 may be moved from a centralized location of all devices 110 to a more localized domain. The user provides, for example, in such an embodiment, by operating a back office equivalent, including an application server and an edge host, depending on the security requirements of the user, on its intranet, as needed. Can take on the role of a trader. This increases the complexity of maintaining and supporting such a system when provided by a third party, but allows for useful configurations when abstractions are defined.

  Further, the arrangement F of FIG. 9 of the exemplary embodiment enables multiple application servers 310 and / or multiple edge hosts 410 to receive communications from the enabled device 110. The arrangement F is, for example, an embodiment in which the elements of the arrangements A, B, D and E are combined. The service 140 can be created to indicate everything needed for the service 140 to communicate in an appropriate manner with the appropriate application server 310 via the appropriate edge host 410. Further, the service host 310 to which the edge host 410 connects the device 110 is not limited to any particular service host or supplier 300, and the service API provided by the edge host 410 enables the connection. As long as it is appropriate to provide services, it can also be connected to related parties.

"Device Model Agent"
For example, in the schematic diagram of FIG. 10, a device model agent (DMA) 120, as previously discussed and shown, is a component that grants the privileges of the end-to-end system 1 according to an embodiment. DMA 120 may be incorporated into device 110, add-on module 115, and / or device / service proxy to provide common device model 122, CIM API 123, and device service environment 124 in which service 140 operates. The role of the DMA is to provide the device 110 with the ability to actively participate in the business processes and services surrounding the device throughout its lifetime. This includes aspects of the Common Information Model Object Manager (CIMOM) from the Distributed Management Task Force (DMTF) and aspects of a new environment for the operation and management of embedded dynamic services. Combine. The agent is responsible for operating the service locally and managing the information provided in the CIM. Agents interact with devices, services (both local services and services distributed throughout a networked environment), and other distributed system components.

  DMA provides a device and independent CIM API as specified by the DMTF, but also provides a device independent service API. Like a software agent, the DMA can work with autonomous and adaptive behavior that occurs locally or through interaction with other distributed components. DMA can also react, for example, again locally or in a distributed manner to events in devices and environments, and in embodiments can involve self-management of services and actions. In a preferred exemplary embodiment, the device independence of the DMA is extended, for example, by the use of the JAVA and J2ME small footprint JAVA standards. Of course, the DMA is not limited to this particular embodiment, but can be incorporated into any suitable software structure with varying degrees of complexity and difficulty providing all features. This exemplary embodiment of DMA uses the J2ME Connected Device Configuration with the Foundation Profile to use the widest range of devices, from large system components with many resources to small systems with limited resources. It is convenient. Again, the device model agent is not limited to this embodiment, and many other embodiments are possible in JAVA or other programming language variants, depending on the needs of the device. The J2ME environment can ensure that the DMA software is device independent and reusable across devices and product platforms. J2ME also provides support for networked and distributed systems, built-in security features, and support for dynamic download and manipulation of code.

  Embodiments preferably include an enhancement of agent device independence by using platform independent standards such as, for example, the JAVA and J2ME small footprint JAVA standards. Of course, the agent is not limited to such an embodiment, but can be embodied in any suitable software structure with varying levels of complexity and difficulty providing all features. Agent embodiments that use the J2ME Connected Device Configuration with the Foundation Profile can enable a wide range of devices, from large system components with many resources to small embedded systems with limited resources. Many other embodiments may use JAVA or other programming language variants as needed, depending on the device in which the agent is embedded or provided by the agent. The J2ME environment is the preferred environment because it ensures that the agent software is substantially device independent and substantially reusable across devices and product platforms. In addition, J2ME includes support for networked distributed systems, built-in security features, and dynamic download and manipulation of code.

  In addition to the advantages described above, DMA allows multiple different data sources to be hidden behind a common provider API. This further abstracts device details from software agents. In an embodiment, the four individual data sources can be lumped behind the common provider and the CIM so that the service does not need to know the details of the data source. For example, data can be managed in this manner in EPSV, PWS, CAN bus, and Web UI. Also, a set of tools can be provided in embodiments that allow the provider layer and CIM included in the device model agent to be easily customized for a given product or device. This allows for reuse and speed because programs that employ or maintain device model agents are only concerned with mapping CIM elements to data sources and not with managing the entire device model agent. Release is promoted.

  The enabling features of the end-to-end architecture of the system components include, in embodiments, appropriate abstractions of the communication methods used between the various distributed components. This abstraction is preferably applied to physical attachment mechanisms as well as protocols down to the session level. Such an abstraction at both levels helps to hide the details of the communication method from the distributed components, so that those components can focus on the operation of the service and the components Or separated from protocol changes. For example, this allows the system to use e-mail over a wireless link or use web services over a dedicated Ethernet link without worrying about which service itself is used. it can.

  This type of abstraction is new to the device and offers several important advantages. It is to provide any given user with the flexibility of the arrangement of system components. Quality of service information that can be expected from any given combination of physical and protocol connections up to the session layer can be conveyed. The system monitors various configurations of quality of service and includes components on the host / back office side that evaluate the effectiveness of the communication link to provide the quality of service required by a given service provided to a particular user. Can be prepared. This is an element of the corresponding and self-monitoring parts of the overall end-to-end system.

  Communication abstraction also provides some fault tolerance. If one connection goes down for any reason, the communication module will detect it and the failed connection will not be known to other parts of the system other than the fact that the quality of service may have changed. Can be replaced with another working connection.

  In embodiments, the service may alternatively be "hard-coded" in the device or proxy. That is, many management functions related to adding and deleting services are not required. The embedded part of the service running on the device must follow web service transactions between distributed components. This allows the back office to handle "hard coded" services as effectively as fully dynamic services in the system.

  Hard-coded services can be enabled by back office subscription. This allows the service provider to control the specific services enabled on any given device, which gives the service provider an idea of how the services provided are based on business needs. To provide the flexibility to decide what will go on the market. For example, a service may be part of a package, may be provided free of charge, may be provided for a fee, may require an update, and may require a separate transaction to provide a complete service. It may be provided on a base.

  Hard-coded services preferably share common basic behaviors for certain requirements and certain extensions. The services preferably have components that work together but run on the intelligent proxy and / or on the device itself in an embedded platform within the back office server. These services are hard coded but can be configured and managed by a service life cycle management system in the supplier / service provider's back office.

  The types of standards that embodiments preferably use include Distributed Management Task Force (DMTF), Web Based Enterprise Management (WBEM), and Common Information Model (CIM). As previously described, CIM provides embodiments with device models and abstractions that allow for reuse of services. In addition, embodiments use web services, XML, various versions of HTTP, and SSL. Embodiments may also use a server-side certificate from, for example, VeriSign, which enables communication across a firewall and the Internet. Embodiments include, for example, Java 2 Micro Edition (J2ME), Embedded Virtual Machine by Insignia Corporation, Java 2 Enterprise Edition (J2EE), BEA WebLogic 7.0 Application Server Technology to enable the application environment in the device and back office. Suite and Oracle8i can be used. Of course, these are merely examples, and other components can be used as needed. Further, new components are likely to be developed that are not currently anticipated and can be added to the system of the embodiments, and such components are within the scope of the embodiments. The services offered, their life cycle, and DMTF CIM extensions for specific products are examples of new technologies that are within the scope of the embodiments.

  Embodiments also allow for the rapid addition and deployment of new services to already deployed systems. For example, shortly after the launch of a new product, a new diagnostic service is developed based on lessons learned from the first three months of operation in the field. The exact nature and behavior of this service was unpredictable at the time the product was launched, so diagnostic services were not included in the launched product. Embodiments allow such diagnostic services to be added to the installed device substantially at any time.

  Embodiments contemplate the service model and internal specifications that a new "service bundle" must contain. Thus, a new code can be downloaded when a new function needs to be added to an existing local device in addition to service authority and configuration information. This feature can be used, according to an embodiment, with a service platform built into devices designed to easily accept new features. Furthermore, when used with the embedded service platform of the embodiments, the CIM embedded in the DMA provides a device independent abstraction so that new code for new services can be reused across the platform. On devices without such a platform, new code can be further added, for example, as a more specialized software download service for patching or upgrading locally, but enabling such services The code is mostly platform specific and therefore cannot be reused much.

  The system of embodiments provides diagnostic routines and other services in a manner that is extremely flexible for the device platform. Such an enabled device will appear to the back office service provider like any other DMA enabled device according to the embodiment. In addition, all services of the device family running locally on the platform inside the device can communicate directly to the supplier system rather than through an intelligent proxy.

  Another variation of the arrangement is to fully incorporate the DMA into the product itself. This embodiment is very similar to the embodiment of Example 1 in that they are both DMA enabled platforms. However, in this example, the small footprint DMA platform is embedded in the product and communicates with both the Print Station Interface Platform (PSIP) and the embedded device controller. The product can accept the limited resources required by the small footprint system, and the placement and integration of the necessary interface components is relatively easy.

  Reusable DMA is a "drop-in" to systems that already have a JVM. Small footprint DMA does not consume system resources and can significantly speed up the implementation of such a platform.

"Automatic meter reading"
Another example of using the deployment flexibility built into the embodiments can be understood by looking at the system from an end-to-end service perspective. In this case, the service is an automated meter reads. This service focuses on obtaining monthly or quarterly meter readings, typically received by telephone, fax, e-mail or web entry, without humans in the loop. This can increase both the accuracy and timeliness of reading, save user time, and improve suppliers' invoice and billing.

  Because the data required from the device is small and largely available, an intelligent proxy can be used, facilitating the involvement of all SNMP-enabled products. This is used with devices that are DMA-capable but are not fully SNMP-compliant, i.e., a wide coverage area can be easily achieved. Again, the abstraction and system modularity in this case is important. The back-office system does not need to know how the device has contacted the supplier (directly or through a proxy), all that is needed is the serial number of the device and the meter reading when scheduled. Can be requested. This separation of the way in which the device can participate in the service and the way in which requests are made from the back office service provider is an advantage in providing deployment flexibility.

"Early Warning System"
In an embodiment, a reporting system, remote monitoring services, and other remote services are combined to form a set of tools to support more tests on site. Basic systems and data collection services can complement data collection systems that rely on human observation and reporting. At the same time, the combination of systems provides greater integrated knowledge that the design team can base on product problem solving activities. In addition, a common model of data collected from on-site equipment creates a mechanism to deploy reporting tools and basic performance reporting functions that can be used across platforms.

"Premium Remote Assistance with Remote Control and Device Service"
One of the basic principles of the embodiments is that the device itself must actively participate in its life cycle and support. This is useful in some situations that report trouble or condition. It can also work with a diagnostic agent built into the device that can monitor system performance and automatically change software or configuration to keep the on-site system operating well. However, many of the problems experienced by users are as related to user problems and operational errors as are related to device failure. Furthermore, as is well known, recording devices are not always remotely repairable due to their complex electromechanical systems.

  In this embodiment, a remote UI and a human-to-human support system are combined to meet the needs of local equipment operational support and to support new ways of working with field operators. Support automation solutions can complement some of the high quality services and support offerings. It automates data collection and remote monitoring, and provides many of the remote services mentioned above. This combination also provides an excellent way to work directly with the equipment operator through a shared UI to assist the operator when additional training, problem solving and software tweaking are required.

"Connection trade-offs"
FIG. 41 illustrates some exemplary options for a communication link between the device at the user site and the back office. There are three main options, labeled A, B and C. Note that only options A and C complete the connection between the device and the supplier's back office on its own. Option B needs to connect to A or C to complete the link back to the supplier.

  Table 2 summarizes the advantages and disadvantages of each option.

  Preferably, all connection options reuse the same back office infrastructure, even if they enter the supplier by different means.

  All options are attractive because, as a group, the options can increase flexibility for deployments that meet different user requirements. The preferred connection method, when feasible, is a wired connection via Option A LAN and the Internet. This is an option with minimal development investment and minimal operating costs. Although this is particularly dominant in the short term, the value of the service has been verified and the resources need to focus on initial service development and do not provide additional ways to connect to the device. However, pursuing only this option does not address unconnected devices that were initially removed from service. In the meantime, each service must consider how to manually include unconnected equipment in the offering.

  The next preferred connection method is long distance wireless with option C mobile phone or two way pager technology. In this configuration, the system can operate seamlessly with a wired device, and enabling this feature will allow any user problems to be resolved if they occur. However, there are several problems with deploying wireless features on a large scale across many products. For example, developing several different add-on modules to be compatible with a very wide range of local products is costly because most systems do not have the same interface to access detailed device data and operations. May be higher. In addition, the additional costs of adding wireless connection and communication costs can be prohibitively expensive, making some services available using that connection. Simple and more easily deployable wireless configurations have inherent limitations on the number and type of services that can be provided, making cost justification difficult. Ultimately, because wireless connection is a way for a supplier / service provider or another party to bypass firewalls and access other resources on the network, Has also expressed concern about having a networked system.

  Finally, option B is a local wireless connection. This method can be used depending on how the local wireless connection technology is specifically incorporated into our user environment and printer.

"Support End-to-End Infrastructure for Equipment Services"
There is a need to support an end-to-end infrastructure for connecting user site devices to legacy systems and business processes. The end-to-end system shown in FIGS. 1 and 2 is an early exemplary embodiment of an end-to-end infrastructure. It supports basic dual mode device involvement (directly and via service proxies) and uses an early service communication and subscription model, for example, via an edge server hosted in the supplier's environment. Use a common entry point for service data and actions. Edge hosts can be partitioned in a manner suitable for additional embodiments, but may also be physically hosted on a single system, thereby increasing the cost of preparation as market acquisition and adoption increase. Be minimized.

  Each field listed in Table 3 represents a field of technical deployment or a field where a third party COTS system must be acquired and investigated. These areas also represent areas for which the full requirements of the technology are not yet known.

  As mentioned above, print products that were not originally designed to support user assisted self-help programs, device-centric services, and / or remote monitoring of ECATs, Such deliverables may be important for speeding up initial shipments and for continuous product success. The need for such a product is to receive daily (or some other period) reports from the local device regarding its condition and how the user has used it. We have called this service remote monitoring. This provides the program team with the ability to identify problems earlier in the field and provides important information that sales, marketing, and support also improve their output.

  One solution to this is to provide on the controller a Device Model Agent (DMA) 120 for Device-Centric Services (DCS) that is locally connected from the controller to the IOT. An add-on component or Customer Services Platform (CS platform) 115 is a solution to this need. The CS platform 115 connects locally to the IOT via one or more of several existing interfaces, provides a unified view of data and functionality, and provides local UI operation and management of local functionality. , May take the form of an embedded system that provides remote connectivity and device centric services to the service platform 124 and the API. CS platform 115 is an embodiment of both DMA 120 and embedded service layer 141 products enabled by service platform 124 within the device-centric services framework.

  Referring to FIGS. 12, 16-19 and 21, the CS platform 115 can preferably take the form of a networked embedded personal computer. Further, add-on components can take the form of a headless box. In any particular form, add-on component 115 is connected to the IOT via at least one physical interface. The CS platform 115 UI can be used with any browser on the local network and is provided by the CS platform 115 embedded web server 130. In a preferred embodiment, the user uses a browser on his DFE as the local UI of the CS platform 115. The CS platform 115 is preferably networked and configured as if any browser were configured to know the local network proxy, firewall password, DNS server IP address, etc. An edge server 410 available on the Internet 400 can be connected. In operation, the CS platform 115 uses this connection to examine messages and instructions and also send the necessary data to support the subscribed service 140. Edge server 410 manages queues, messages, services, and transactions associated with the end-to-end operation of device services.

  The CS platform 115 is preferably a platform utilizing a low cost embedded personal computer with a motherboard 701 and an embedded software operating system 704 such as Linux, although other operating systems may be used. it can. The add-on component 115 can be customized by hardware such as auxiliary I / O and the static memory board 702, but such customization is preferably minimal to keep costs down. Component 115 is designed so that the internal hardware platform can change over time to follow the price curve of the smallest general purpose personal computer that can reduce the cost of the platform by two-thirds. . As the internal storage medium 703, a memory such as a compact flash (registered trademark) memory having higher reliability than a hard disk drive can be used. Also, using compact flash memory lowers the cost of upgrading CS platform 115 if additional storage resources are needed for new services 140 deployed, and compact flash memory is typically more Looks like a hard disk drive. Further, the use of standard personal computer technology for add-on components 115 allows for quick revision following a cost curve, and standard add-on technologies (eg, web cameras) may be compatible with the platform. Easy and guaranteed.

  Examples of connection paths between the CS platform add-on component 115 and the device IOT include the Fuji Xerox protocol and interface Electronic Partner (EPSV) 712-714, RS422 and / or RS232 serial ports 715, 716, service There are connections PWS 717-718, CAN bus connections 719-721, and USB (not shown) used by the customer support engineer to connect the laptop to the device. Also, additional interfaces, such as a proprietary interface to the digital front end, can be monitored to provide additional data for service and system management activities. In particular, since CS platform 115 is preferably designed not to be limited to such connections, other connections are also within the scope of embodiments.

  It preferably includes a router 730, which is responsible for managing a large amount of information and manipulating the preemption of some activities when another connection becomes active. Thus, the communication is implemented such that the communication can be performed without data corruption issues.

  The embedded software system preferably supports both locally hosted functions, such as the aforementioned diagnostic routines, and services that can be dynamically added and configured to provide flexible components. Thus, embodiments include a system component that incorporates the DMA 120 based on a device-centric service platform, an embedded JVM that allows the CS platform 115 to act as a local enabler of the system and actively participate in device-centric services, and Intended for web servers.

  Embedded DMA 120 allows service 140 to be provided directly from device 110, regardless of the digital front end and / or ability to execute DMA 120 on its own. This allows the device 110 to actively participate in the service offering via the DCS service model. Add-on component 115 also provides a programmatic interface for new services 140 configured around the system, which allows for a fast and robust solution integrated with the product. In addition, the inclusion of the web server 130 in the add-on component 115 allows for direct web service transactions and services between the CS platform 115 as an interface for the IOT and the remote service offering.

  The IOT diagnostic routine 740 customized for trained users rather than customer support technicians provides an easy-to-use and internationalized UI for the predefined diagnostic routines already provided by IOT. The diagnostic routine can, for example, optimize the toner density level and obtain uniform image quality (highest setting 741). Another service 742 that can be provided is Belt Edge Learn, a routine that learns about new intermediate belt edges to improve lateral positioning and belt handling performance. The purpose of Belt Edge Learn is to track belt movement using two belt edge sensors. Using the data received from these sensors, the IOT automatically adjusts using a belt tracking roller / motor / sensor to ensure that the belt rotates without inboard / outboard motion. Still other services include, for example, RegiCon, a setup routine that sets up the complete image found in the IOT on the image registration system, and Halftone, a setup routine that adjusts the halftone density printed by the system. is there. Printing a halftone pattern allows a user to set a constant gray level throughout the page. Since almost all image quality defects appear in halftone patterns, the halftone patterns themselves are used to diagnose problems.

  CS platform add-on 115 preferably uses a web-based UI via an embedded web server. This reduces the hardware cost of the CS platform 115 itself, but instead uses monitor, keyboard and mouse hardware that is almost always present and associated with the digital front end of the networked device 110 I do. It is also accessible from other networked PCs by a suitable browser on the local network. Such a UI offers high operability and extensibility of new services and features over time. The cost of providing a GUI only for this application is prohibitive. In embodiments, the web-based UI can include context-sensitive help and links to call centers and other support sites, making the system easier to use. The UI can be used with any browser connected on the user's LAN, including, for example, a personal computer connected to a hard-wired network. In addition, if the wireless access point is directly connected to the CS platform 115 or mounted on the user's network, use a wirelessly connected personal or handheld computer with a compatible browser as the UI be able to.

  The device-centric services add-on component 115 of the embodiment preferably has some services pre-loaded and licensed, but this may not be necessary. The CS platform follows the device-centric service model of the subscribed service offering. PDT has decided to enable the basic service set. Further, the components are preferably enabled for CS platform firmware software downloads and remote upgrades upon notification from the remote site.

  Preferably, the system periodically contacts the remote DCS host 310 or 410 via the synchronization service to see if new transactions are waiting. One of them is that new software may be available for the system. If available, the user can be notified by an upgrade status screen available from the Administration tab. The user can also select to manually check for updates via the refresh status button on the software upgrade screen. If an upgrade is available, the user can choose to accept the upgrade. If accepted, the software download process automatically downloads the required latest version, installs it, saves the older version, and restarts the system.

  Component 115 returns a secure, encrypted communication to the vendor that supports the eService offering. The diagnostic routine of the embodiment is treated as a service even if the operation is completely local. The service can then be controlled by the service subscription model used for all services. Thereby, when necessary, the function of the CS platform can be effectively disabled.

  Preferably, the system can provide an initial set of services to the user. Such early offerings include, for example, automatic billing, automatic supply replenishment, and remote monitoring. Automatic billing is preferably a subscription service that reports the required billing meter to the supplier, either on demand or automatically, via the device-centric service infrastructure. Automatic supply replenishment, as the name implies, is used to provide the supplier with the necessary information to ensure that meter supplies are delivered to the user's site in a timely and accurate manner without human intervention. Preferably, the subscription service tracks events, area coverage events, and toner bottle change events. Remote monitoring is preferably a service that periodically collects a configurable data set found in the system, models it in a standard way, and returns it to the supplier. Examples of types of data found in the service include billing meter, IOT failure, media path blockage, image area coverage, media usage (weight, size, and type), feature usage, toner status, There are statuses for simplex / duplex printing, media tray usage, reduction and enlargement, copy mode, and frequent service items.

  Additional service sets can be incorporated into the system to ensure proper system operation. For example, a DMA housekeeping service, a health monitor, a DMA-IOT communication status monitor, a service synchronization service, etc., which periodically contact the remote part of the DMA system to determine new instructions or activities that the DMA should perform. It is a service to check if there is.

  To ensure security, add-on component 115 uses standard secure web data transmission techniques and certificates in embodiments. For example, VeriSign certificates, RSA encryption, SSL, and related technologies can be used. Additionally, add-on component 115 can provide a detailed transaction log that allows a user to review all messages sent from the device. All transactions sent from CS platform 115 can be logged in XML format before being packaged for transmission or encryption. This provides another layer of inspection functionality by the user to increase the reliability of the supplier's statement that they are only sending what they really say.

  In embodiments, three permission levels may be invoked before sending data to the edge host 410. The contractual arrangement is expected to state that the data is sent automatically and that the user can check the transmission log. For users who need to make various arrangements, options corresponding to multiple permission levels are built into the system. The levels are Audit and Log, which keeps a record of all transactions in a transaction log, and user representatives by screen messages, emails or some other means when back office transmission is achieved. The Simple Notification that notifies the user and Approval Before Sending that maintains a queue of messages to the back office 300 and notifies the user representative when the queue is not empty. Can be. In the post-approval transmission, the user representative may examine the message as needed and then allow the data to be transmitted. The default permission levels are configurable, but the preferred shipping default levels are audit and log. Pre-assistance self-help tools and diagnostic access of the IOT itself also have one password for all functions. Earlier systems had no way to handle the roles of multiple people and manage passwords accordingly.

  In an embodiment, a number of roles that are enabled include, for example, a Technical Key Operator (TKO), a Customer Service Engineer (CSE), and a System Administrator ( SA). The system for configuring access for any given role is provided by a web-based GUI. Preferably, the password is initially set to a common password that is individualized for each role. The system of the embodiment is intended to allow SAs to configure their own passwords and manage TKO passwords so that they can be networked using standard IT industry processes, protocols and procedures. Role-based password management, and remotely authenticated login and password management for any or all roles. Remote login can be particularly attractive to CSEs who want to use the same password on any CS platform 115 they visit. Authentication of the remote login may be a password alone, a password and token combination, or any other suitable method. This is limited by the network connectivity of the CS platform to the remote host site, and a backup (or local) common CSE or user role password needs to be provided.

  The platform may also include a process to remotely reset a forgotten local password. The SA invokes the help desk and is successfully authenticated as the talking person. The help desk issues a command to the CS platform (indicated by the IOT serial number), causing it to reset its SA password. The SA presses the SYNC button by hand, causing the CS platform to contact the edge host 410, receive a command to reset the SA password, and signal the operation to be completed. If all else fails the CS, all passwords can be reset to the default configuration according to the platform factory reset procedure.

  A new software service 140 can be added to the CS platform add-on component through the normal DCS service subscription and activation process. The subscribed services can be automatically managed and introduced by the DMA 120 and the DCS end-to-end system 1. This allows the CS platform 115 to provide new services over time. New software upgrades can be provided by the remote software upgrade feature of the CS platform. This allows more important upgrades of the CS platform 115 to be performed with user approval without the need for a technician to visit the user site. This greatly reduces costs and increases the frequency with which system upgrades can be deployed.

  Because of the above features and the use of COTS technology for most system hardware and software, new hardware can be added with the appropriate services added remotely to the platform. An example of a new service that requires hardware expansion is webcam-based support for users. By adding a low-cost USB web cam, the CS platform 115 allows the user to take a snapshot of the problem they are having and send it to a help desk or call center. Can provide the subscribed user with a service that can receive an appropriate remote service.

  Embodiments contemplate the introduction of the CS platform on a personal computer networked on the same subnet as the CS platform 115. The installation process is shown schematically in FIG. 19 and proceeds with the installer process using a combination of standard network utilities and LED indicators behind the CS platform. Since the CS platform 115 is preferably a headless embedded system, the installation process can be tricky. The steps shown here are one possible way of performing the installation, but other methods are also possible. The combination of the feedback on the command screen and the LED of the device provides a reliable process for installation. Component 115 is initially in a power-on standby state (block 801) and is powered on by a user (block 802). A status LED or the like preferably flashes to indicate that the component 115 is starting up, and then turns on when the component 115 is ready (block 803). In an embodiment, the user reads the MAC address of component 115 (block 804), opens a command window in the UI (block 805), and enters a command along with the MAC address and other information (block 806). Next, the user pings component 115 (block 807) to test the component, and then waits for a completion indication such that one or more LEDs are on (block 807). 808). Next, the user proceeds to the component web server 130 with a browser (block 809), logs on as an administrator (block 810), configures network information as needed (block 811), and component 115 Can communicate with the edge host 410. Component 115 restarts, during which time the IOT must be powered down (block 813). After both restarts are completed, the installation and setup are complete (block 813).

  The CS platform can be configured in several ways for network connection, including the use of fixed IP addresses and the use of DHCP to obtain IP addresses. A fixed address is preferred for most users and has the advantage of making it easier to show the browser to the CS platform UI when ready. Instead, DHCP is very easy to implement, but requires a device domain name for the CS platform and DNS service connection. One possible way to provide an automatic domain name is to combine the IOT serial number with the last two digits of the MAC address. Other combinations of readily available information known to the user and the default CS platform are possible.

  The CS platform is configured for the network just as any browser is configured. This can be done manually by filling out a form on the CS Platform UI. If the OS has a look-up function for checking the settings already in the web browser platform, the function can be performed by the function. This provides a baseline setting, which the user can then customize and modify as needed. After configuration, a test configuration button may be provided to immediately contact the supplier edge server 410 and verify that the settings are correct before the user exits the network administration page.

  Users of the CS platform 115 may lose bookmarks to the CS platform web page and need to provide a way to make it easier for the user to find the web page again. If DHCP is used to configure the system, the user can simply follow the instructions to determine the default or hard-coded domain name for the CS platform. It can also provide a discovery tool that installs and runs on a DFE or networked personal computer in the user's environment and finds and displays all CS platforms. This discovery tool can also be downloaded from the supplier's web site. A link to the tool can be used from the CS Platform UI and can therefore be downloaded and saved in case of loss of the CS Platform IP address. The tool can also be stored locally on the CS platform with the option to save locally to the DFE during installation.

  As described above, the router manages the method of parallel access to the CS platform. The CS platform router is preferably compatible with supplier gateway and DMA requirements and on-site equipment 110. The router provides a direct connection between the local PWS port and the IOT diagnostic (serial) port. The router of the embodiment may also provide network connectivity to network clients, for example, via an IOT diagnostic (serial) port, and support a network path to the IOT CAN bus and EP services of various devices 110; Arbitrate all (other than EP) communication traffic and priorities. The priority is enabled so that the operation mode can smoothly transition. For example, there is an application session priority for DCU software upgrade, another priority for IOT serial port 3 local PWS port IOT diagnostic session, and another priority for other network sessions. In normal system operation, "open" local PWS sessions are preferably not preempted, and local PWS session requests can preferably interrupt network diagnostic application sessions. All interruptions must be appropriate. Preferably, reemption of network DCU software upgrade sessions is unacceptable, but EP and / or CAN bus sessions are always allowed as long as only one CAN session is allowed at a time. . The DMA EP gateway server / client client preferably has exclusive access to the EP port, and DCU V2.0 preferably supports the path of local PWS transactions over the network.

  In support of DCU v2.0, the communication controller generates, for example, a START_DIAG_SESSION event (the customer of this event is a DMA push event provider) and an END_DIAG_SESSION event (the customer of this event provides a DMA push event provider). And send each message between the LOCAL_PWS_PORT and the IOT_SERIAL communication port as a PWS_MESSAGE_EVENT to the DMA push event provider to provide the contents of the local CSE diagnostic session on the network. .

  In yet another support for DCU v2.0, the communication controller provides a way to signal the presence to a PWS connected to the system, for example, by utilizing an RS232 signal specified as a CTS (Clear To Send) signal. This can support a local CSE diagnostic connection to an IOT serial port via a local PWS port. The CTS signal is preferably held at a logic high level on the DCU.

  The RS232 interface DSR (data signal ready) signal can control the diagnostic mode of the IOT. The DCU saves or "creates" this control as needed. If the IOT is powered off in diagnostic mode, it will start up in diagnostic mode when the DSR signal to the IOT is set high. PSW controls the DSR signal.

  Although particular embodiments have been described, alternatives, modifications, variations, improvements and substantial equivalents may now appear to applicants or those of ordinary skill in the art that are not or cannot be predicted. It is therefore intended that the appended claims filed and amended include all such alternatives, modifications, variations, improvements and substantial equivalents.

FIG. 1 is a schematic diagram of the overall architecture of an embodiment. FIG. 4 is another schematic diagram of the overall architecture of the embodiment. FIG. 2 is a schematic diagram of a service application and arrangement method according to an embodiment; FIG. 4 is a schematic diagram of an arrangement option according to the embodiment. FIG. 4 is a schematic diagram of additional placement options according to an embodiment. FIG. 4 is a schematic diagram of additional placement options according to an embodiment. FIG. 4 is a schematic diagram of additional placement options according to an embodiment. FIG. 4 is a schematic diagram of additional placement options according to an embodiment. FIG. 4 is a schematic diagram of additional placement options according to an embodiment. FIG. 4 is a more detailed schematic diagram of a device model agent according to an embodiment, and a more detailed schematic diagram of the interaction between a device, a device model agent, a service proxy and a service host according to an embodiment. FIG. 4 is a more detailed schematic diagram of the interaction between a device, a device model agent, a service proxy, and a service host according to an embodiment. FIG. 4 is a schematic diagram of additional placement options according to an embodiment. FIG. 9 is a schematic diagram of additional deployment options according to an embodiment, further emphasizing the relationship between a device model agent and its device. FIG. 7 is a schematic diagram of additional deployment options according to an embodiment, further emphasizing the device model agent and its relationship to the device from another perspective. 4 is a schematic flowchart of a method of operating a service manager of a device model agent according to an embodiment. FIG. 4 is a schematic diagram of a CS platform add-on component according to an embodiment. FIG. 5 is another schematic diagram of a CS platform add-on component according to an embodiment. FIG. 3 is a schematic diagram of a wireless deployment scheme of a CS platform add-on component according to an embodiment. FIG. 7 is a schematic diagram of a method for setting a CS platform add-on component according to an embodiment; It is a schematic diagram of a correspondence server by an embodiment. FIG. 4 is a more schematic diagram of a CS platform add-on component according to an embodiment.

Explanation of reference numerals

  100 user environment, 110 local devices, 120 distributed device agents, 130 web servers, 200 application servers, 210 device proxies, 220 user applications, 300 service delivery systems, 310 application servers, 320 host systems.

Claims (25)

At least one device capable of providing at least one available service from a service host, including at least one device-specific provider application program interface, and having device-specific status information;
At least one service tier;
At least one service environment in which at least one service actually operates, at least one common information management application program interface, at least one device model agent, and at least one common provider application program interface A device independent runtime environment including:
Distributed system architecture, including. The distributed system architecture of claim 1, wherein:
A distributed system architecture in which at least one service layer includes at least one service made available to at least one device. The distributed system architecture of claim 1, wherein:
A distributed system architecture, wherein at least one device independent runtime environment is located within the recording device, wherein the recording device is one of the at least one device. The distributed system architecture of claim 1, wherein:
A distributed system architecture, wherein at least one device independent runtime environment is located in a server connected to the recording device, wherein the recording device is one of the at least one device. The distributed system architecture of claim 4, wherein:
A distributed system architecture in which a server hosts applications whose primary functions are not associated with a device-independent runtime environment, but hosts the device-independent runtime environment. The distributed system architecture of claim 1, wherein:
At least one service environment and a service layer are on a server connected to the recording device, wherein the recording device is one of the at least one device, and the server associates a main function with the service layer and the environment. A distributed system architecture that hosts applications that are not yet hosted on their service tier and environment. The distributed system architecture of claim 1, wherein:
The device model agent, at least one service environment, and the service layer are on a server connected to the recording device, wherein the recording device is one of the at least one device, and the server has a main function. A distributed system architecture that is not associated with a device model agent, service tier, and service environment, but hosts an application that hosts the device model agent, service tier, and service environment. A method for providing a device independent service includes:
Providing a common device interface;
Providing a common information model;
Integrating services within the device using a common device interface and information model;
Hiding device-specific differences behind a common device interface;
A method that includes 9. The method of claim 8, wherein
A method wherein providing a common device interface comprises using a distributed model task force common information model with predetermined extensions of respective services. 10. The method of claim 9, wherein
A method wherein the step of providing a common information model comprises a step based on a distributed model task force common information model with predetermined extensions to enhance compatibility between devices and respective services. A method of providing a platform,
Providing an access module;
Enabling the service to use the built-in computing power, data, and functions of the device with the access module;
Arranging access modules in a common manner;
A method that includes The method of claim 11, further comprising accepting the newly deployed service asynchronously with a software release for the hosting platform. The method according to claim 11, wherein
A method further comprising incorporating the service platform into a host platform. The method according to claim 11, wherein
A method further comprising deploying a service platform in an add-on component to a host device. The method according to claim 14, wherein
The method further comprising connecting the add-on component to the host device via at least two interfaces. The method according to claim 14, wherein
A method further comprising connecting the add-on component to a network, thereby providing the host device with the ability to participate in device services. The method according to claim 14, wherein
The method further comprising providing all network connections of the host device via add-on components. The method according to claim 11, wherein
A method further comprising using at least one application located in a user environment as a service proxy between at least one device and a service host. The method according to claim 18, wherein
The method of using, comprising transmitting at least data from the device to the service proxy in a first protocol and transmitting data from the service proxy to a service host in a second protocol. 20. The method according to claim 19, wherein
The method wherein the first protocol is SNMP. 20. The method according to claim 19, wherein
The method wherein the first protocol is a wireless communication protocol. 20. The method according to claim 19, wherein
The method further comprising managing device variability at the service host using the device-based service response system. 20. The method according to claim 19, wherein
A method further comprising integrating service management into a server in a user environment. 20. The method according to claim 19, wherein
The method further comprising providing a UI that allows a user to manage the service.   A device model agent that provides an environment in which a service can operate substantially independently of a device intended to provide functionality while accessing the device, the device model agent comprising: at least one service host; A device model agent that communicates and enables automated supply maintenance and subscription and deployment of services.

Images