Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Office Action is in response to the communication and claim amendment filed on 03/02/2026; Claims 1, 13, and 15 have been amended; Claims 5-9 and 17-19 were cancelled; Claims 1 and 13 are independent claims. Claims 1-4, 10-12, 13-16, and 20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
The objection to the claim 17 is withdrawn as the claim has been canceled.
Applicants’ arguments with respect to amended limitations “classifying an authenticated user as an internal stakeholder or an external stakeholder, wherein the internal stakeholder includes an administrator, a planner, a developer, a producer, or an operator, wherein the external stakeholder includes a customer or a cooperative company, and wherein the controller controls the access authority to the asset information for each of the administrator, the planner, the developer, the producer, the operator, the customer, or the cooperative company according to the asset status,” have been fully considered but are moot in view of the new ground(s) of rejection.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/10/2025 is being considered by the examiner.
Claim Objections
Claims 1, 4 and 12 are objected to because of the following informalities:
Regarding claim 1, claim 1 recites the limitations “a controller that controls …,” and “wherein the controller updates/classifies/controls ….” To properly recite embodiments and corresponding of a system claim, it’s suggested that the aforementioned limitations be further amended to “a controller configured to control …,” and “wherein the controller further configured to update/classify/control ….,” respectively.
Regarding claims 4 and 12, claims 4 and 12 recite the limitations “the controller performs …,” and “the controller categorizes ….” To properly recite embodiments and corresponding of a system claim, it’s suggested that the aforementioned limitations be further amended to “the controller configured to perform …,” and “the controller configured to categorize ….,” respectively.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 10-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Redmond Johannes Schmitt et al. (“Schmitt,” Authorization in asset administration shells using OPC UA”, May 14th, 2019, pages 429-442), and Nelaturi et al. (“Nelaturi,” US 2019/0197448), and Krueger (“Krueger,” US 2021/0192470), and further in view of Hen et al. (“Hen,” US 2022/0366039).
Regarding claim 1, Schmitt teaches a system for managing asset information of a smart factory and managing access to the asset information, the system comprising:
a memory that stores the asset information (Schmitt: page, 434, “OPC UA server configure OPC UA server specific access rights or as part of AAS or submodels to provide common applicable roles and access rules”; page 431, “an AAS consists of submodels, each modeling different aspects of a device. Each submodel contains a collection of elements, e. g., properties or operations”; page 430, “The system designers, the asset users, the applications, the processes and the asset itself update the information of the AAS during the life of the asset”; page 432, “the content of the AAS evolves as the asset enters various lifecycle phases.”. Person of ordinary skill in the art (POSITA) would understand that such AAS information must necessarily be stored in memory/database/server structures); and
a controller that controls an access authority of an authenticated user to the asset information according to an asset status of the asset information (Schmitt: page 434, “OPC UA server specific access rights or as part of AAS or submodels to provide common applicable roles and access rule”; page 430, “authorization and access control are required; page 431, section 2.1 Authorization concepts in AAS, “The "Details of the Administration shell" specification [6] adopts attribute-based access control (ABAC). In ABAC, attributes are used to describe an access request. This includes the subject (e.g., the user), the accessed object (e.g., submodels or properties of the AAS), the access nature (e.g., read) and the context of the access (e.g., time of day).”; page 430, 1.1. Example user case: “information about an asset (e. g., a machine) is made accessible for different roles throughout the product life cycle”; page 432, Requirement 4: Support for flexible access rights. AAS may contain information about various lifecycle aspects of an asset; hence, the content of the AAS evolves as the asset enters various lifecycle phases. This means that the content of an AAS is not fixed-it may change. The dynamic nature of AAS content means that access rights to the AAS content must also be defined in a flexible manner),
Schmitt teaches an asset status of the asset information as recited above but does not explicit teach “wherein the asset status includes plan, development, production, and maintenance.”
However, in an analogous art, Nelaturi discloses wherein the asset status includes plan, development, production, and maintenance (Nelaturi: par. 0001, The present disclosure is directed to the development of hardware and software services for use in connection with product lifecycle management (PLM), where today such services are commonly designed and implemented as monolithic systems. PLM systems are, as exemplary shown in FIG. 1, intended to systematically improve and integrate various phases of a product's lifecycle 100, including identification of need 102, conception of the product 104, design/development (including conceptual, preliminary, and detailed design, simulation/analysis, optimization/synthesis) 106, manufacturing/production (including process planning and execution, quality control inspection) 108, and other actions after its sale such as maintenance and recycling 110 (it is understood that FIG. 1 is simply one example of a representation of a PLM environment.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Nelaturi with the method and system of Schmitt to include wherein the asset status includes plan, development, production, and maintenance. One would have been motivated to provide workflow flexibility at an optimized cost, thereby avoiding situations for example where a small/medium sized business pays tens of thousands of dollars for sophisticated monolithic PLM software although they use only a small subset of the software tools packaged into the PLM system (Nelaturi: par. 0003).
Schmitt and Nelaturi do not explicitly disclose “wherein the controller updates the asset status based on a current state of the smart factory.”
However, in an analogous art, Krueger discloses wherein the controller updates the asset status based on a current state of the smart factory (Krueger: par. 0032, a smart factory may include facilities and equipment that communicate updates to one another related to various lifecycle events for assets, such as when a stage in a manufacturing process is complete for a given asset).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krueger with the method and system of Schmitt and Nelaturi to include wherein the controller updates the asset status based on a current state of the smart factory. One would have been motivated to provide to so because the internet of things (IoT) technology allows large amounts of data to be gathered, thus, facilitating the ability to predict failures and react before they occur. By allowing data about assets to be securely and verifiably tracked and managed throughout their lifecycles, the method can improve the utility and security of asset management systems. By providing the unified system that can be accessed by all interested parties and that also receives data directly from assets, the method can improve the functioning and accessibility of asset management systems (Kruger: pars. 0032, 0033, 0035).
Schmitt, Nelaturi, and Krueger do not explicitly disclose “wherein the controller classifies the authenticated user as an internal stakeholder or an external stakeholder, wherein the internal stakeholder includes an administrator, a planner, a developer, a producer, or an operator, wherein the external stakeholder includes a customer or a cooperative company, and wherein the controller controls the access authority to the asset information for each of the administrator, the planner, the developer, the producer, the operator, the customer, or the cooperative company according to the asset status.
However, in an analogous art, Hen discloses
the controller classifies the authenticated user as an internal stakeholder or an external stakeholder (Hen: par. [0022], FIG. 2 illustrates an example computer network 200, such as a local network, a cloud computing network, or a combination of networks that may include a set of users 202 such as users of an enterprise, a set of network items 204 such as enterprise resources accessible or accessed by the users 202, a role-based access controller 206 to restrict network access of the network items 204 grounded on roles of users 202 within the enterprise, and a permissive role definition detector 208 to detect abnormal or highly permissible role definitions in the role-based access controller 206 and to take action to address the abnormal or highly permissible role definition; par. 0023, In the example, the role-based access controller 206 can provide access privileges to information in network items 204 that users 202 apply to do their jobs and prevents users 202 from accessing information that does not pertain to them. In a role-based access control model, a user's role in an enterprise determines the permissions that user is granted and provides that certain employees, for example, cannot access sensitive information or perform high-level tasks that are irrelevant to their jobs. In the role-based access control data model, roles can be determined from several factors, including authorization, responsibility and job competency. As such, enterprises can designate whether a user is an end user, an administrator or a specialist user. In addition, access to network resources can be limited to specific tasks, such as the ability to view, create or modify files. Limiting network access may be applicable for enterprise that have many employees, employ contractors or permit access to third parties, like customers and vendors, which makes access monitoring difficult. The role-based access controller 206 can provide for fine-grained access management to network items 204),
wherein the internal stakeholder includes an administrator, a planner, a developer, a producer, or an operator (Hen: par. [0022], []In a role-based access control model, a user's role in an enterprise determines the permissions that user is granted and provides that certain employees, for example, cannot access sensitive information or perform high-level tasks that are irrelevant to their jobs. In the role-based access control data model, roles can be determined from several factors, including authorization, responsibility and job competency. As such, enterprises can designate whether a user is an end user, an administrator or a specialist user),
wherein the external stakeholder includes a customer or a cooperative company (Hen: par. [0022], [] In addition, access to network resources can be limited to specific tasks, such as the ability to view, create or modify files. Limiting network access may be applicable for enterprise that have many employees, employ contractors or permit access to third parties, like customers and vendors, which makes access monitoring difficult []), and
wherein the controller controls the access authority to the asset information for each of the administrator, the planner, the developer, the producer, the operator, the customer, or the cooperative company according to the asset status (Hen: par. 0023: In the example, the role-based access controller 206 can provide access privileges to information in network items 204 that users 202 apply to do their jobs and prevents users 202 from accessing information that does not pertain to them. In a role-based access control model, a user's role in an enterprise determines the permissions that user is granted and provides that certain employees, for example, cannot access sensitive information or perform high-level tasks that are irrelevant to their jobs. In the role-based access control data model, roles can be determined from several factors, including authorization, responsibility and job competency. As such, enterprises can designate whether a user is an end user, an administrator or a specialist user , and in combination with Schmitt: page 434, “OPC UA server specific access rights or as part of AAS or submodels to provide common applicable roles and access rule”; page 430, “authorization and access control are required; page 431, section 2.1 Authorization concepts in AAS, “The "Details of the Administration shell" specification [6] adopts attribute-based access control (ABAC). In ABAC, attributes are used to describe an access request. This includes the subject (e.g., the user), the accessed object (e.g., submodels or properties of the AAS), the access nature (e.g., read) and the context of the access (e.g., time of day).”; page 430, 1.1. Example user case: “information about an asset (e. g., a machine) is made accessible for different roles throughout the product life cycle”; page 432, Requirement 4: Support for flexible access rights. AAS may contain information about various lifecycle aspects of an asset; hence, the content of the AAS evolves as the asset enters various lifecycle phases. This means that the content of an AAS is not fixed-it may change. The dynamic nature of AAS content means that access rights to the AAS content must also be defined in a flexible manner; Nelaturi: par. 0001; Krueger: par. 0032).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hen with the method and system of Schmitt, Nelaturi, and Krueger to include wherein the controller classifies the authenticated user as an internal stakeholder or an external stakeholder, wherein the internal stakeholder includes an administrator, a planner, a developer, a producer, or an operator, wherein the external stakeholder includes a customer or a cooperative company, and wherein the controller controls the access authority to the asset information for each of the administrator, the planner, the developer, the producer, the operator, the customer, or the cooperative company according to the asset status. One would have been motivated to provide receiving the role definition for the security principal over the scope of resources in which the role definition includes the built-in role and the custom role, thus preventing access to the resources, alerting an administrator, or actively allowing the access (Hen, par. 0004).
Regarding claim 2, the combination of Schmitt, Nelaturi, Krueger, and Hen teaches the system of claim 1. The combination of Schmitt, Nelaturi, Krueger, and Hen further teaches, wherein the asset status is a status in time-series (Schmitt: page 432, Requirement 4: Support for flexible access rights. AAS may contain information about various lifecycle aspects of an asset; hence, the content of the AAS evolves as the asset enters various lifecycle phases. This means that the content of an AAS is not fixed-it may change. The dynamic nature of AAS content means that access rights to the AAS content must also be defined in a flexible manner; Nelaturi: par. 0001, The present disclosure is directed to the development of hardware and software services for use in connection with product lifecycle management (PLM), where today such services are commonly designed and implemented as monolithic systems. PLM systems are, as exemplary shown in FIG. 1, intended to systematically improve and integrate various phases of a product's lifecycle 100, including identification of need 102, conception of the product 104, design/development (including conceptual, preliminary, and detailed design, simulation/analysis, optimization/synthesis) 106, manufacturing/production (including process planning and execution, quality control inspection) 108, and other actions after its sale such as maintenance and recycling 110 (it is understood that FIG. 1 is simply one example of a representation of a PLM environment).
Regarding claim 3, the combination of Schmitt, Nelaturi, Krueger, and Hen teaches the system of claim 1. The combination of Schmitt, Nelaturi, Krueger, and Hen further teaches wherein the asset status is a status following a lifecycle of an asset (Schmitt: page 432, Requirement 4: Support for flexible access rights. AAS may contain information about various lifecycle aspects of an asset; hence, the content of the AAS evolves as the asset enters various lifecycle phases. This means that the content of an AAS is not fixed-it may change. The dynamic nature of AAS content means that access rights to the AAS content must also be defined in a flexible manner; Nelaturi: par. 0001, The present disclosure is directed to the development of hardware and software services for use in connection with product lifecycle management (PLM), where today such services are commonly designed and implemented as monolithic systems. PLM systems are, as exemplary shown in FIG. 1, intended to systematically improve and integrate various phases of a product's lifecycle 100, including identification of need 102, conception of the product 104, design/development (including conceptual, preliminary, and detailed design, simulation/analysis, optimization/synthesis) 106, manufacturing/production (including process planning and execution, quality control inspection) 108, and other actions after its sale such as maintenance and recycling 110 (it is understood that FIG. 1 is simply one example of a representation of a PLM environment).
Regarding claim 4, the combination of Schmitt, Nelaturi, Krueger, and Hen teaches the system of claim 1. The combination of Schmitt, Nelaturi, Krueger, and Hen further teaches wherein the controller performs control to receive information about the asset status from a server that manages an asset (Schmitt: page 432, Requirement 4: Support for flexible access rights. AAS may contain information about various lifecycle aspects of an asset; hence, the content of the AAS evolves as the asset enters various lifecycle phases. This means that the content of an AAS is not fixed-it may change. The dynamic nature of AAS content means that access rights to the AAS content must also be defined in a flexible manner;Krueger: par. 0032, a smart factory may include facilities and equipment that communicate updates to one another related tovarious lifecycle events for assets, such as when a stage in a manufacturing process is complete for a given asset; Nelaturi: par. 0001, The present disclosure is directed to the development of hardware and software services for use in connection with product lifecycle management (PLM), where today such services are commonly designed and implemented as monolithic systems. PLM systems are, as exemplary shown in FIG. 1, intended to systematically improve and integrate various phases of a product's lifecycle 100, including identification of need 102, conception of the product 104, design/development (including conceptual, preliminary, and detailed design, simulation/analysis, optimization/synthesis) 106, manufacturing/production (including process planning and execution, quality control inspection) 108, and other actions after its sale such as maintenance and recycling 110 (it is understood that FIG. 1 is simply one example of a representation of a PLM environment; Hen: pars. 0022, 0023).
Regarding claim 10, the combination of Schmitt, Nelaturi, Krueger, and Hen teaches the system of claim 1. The combination of Schmitt, Nelaturi, Krueger, and Hen further teaches wherein the asset information is managed based on an Asset Administration Shell (AAS) (Schmitt: abstract, page 429, "The core concept for I4.0 is the digital twin or asset administration shell (AAS)...It shall provide a machine-readable description of I4.0 components, being available over the entire lifecycle"; page 429-430, 1. Motivation, The asset administration shell (AAS) is the standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems" [] such a representation can be seen as a container that builds up a common digitally accessible facade around an asset [] The system designers, the asset users, the applications, the processes and the asset itself update the information of the AAS during the life of the asset until its disposal").
Regarding claim 11, the combination of Schmitt, Nelaturi, Krueger, and Hen teaches the system of claim 10. The combination of Schmitt, Nelaturi, Krueger, and Hen further teaches wherein the AAS includes multiple submodels that change depending on the asset status (Schmitt: page 431-432, Requirement 1: Authorization on AAS submodel level. "Submodels are defined as part of the AAS specification to organize and structure the contents within the AAS. Different submodels can be defined and used for different aspects of an asset. Submodels can be seen as the base unit of information exchange among stakeholders/roles."; Requirement 3: Support for AAS views. "In addition to submodels, an AAS can also define views. A view references an arbitrary number of elements within an AAS...For example, there can be views dedicated to different lifecycle phases of a device."; Requirement 4: Support for flexible access right. "AAS may contain information about various lifecycle aspects of an asset; hence, the content of the AAS evolves as the asset enters various lifecycle phases. This means that the content of an AAS is not fixed -it may change. The dynamic nature of AAS content means that access rights to the AAS content must also be defined in a flexible manner.").
Regarding claim 12, the combination of Schmitt, Nelaturi, Krueger, and Hen teaches the system of claim 10. The combination of Schmitt, Nelaturi, Krueger, and Hen further teaches0 wherein the AAS includes at least one submodel containing multiple attributes divided according to asset information authority (Schmitt: page 432, Requirement 1: Authorization on AAS submodel level. "Submodels are defined as part of the AAS specification to organize and structure the contents within the AAS. Different submodels can be defined and used for different aspects of an asset. Submodels can be seen as the base unit of information exchange among stakeholders/roles.". Different submodels can be defined and used for different aspects of an asset" ; page 434, 3.2 Recommended solution: Schmitt teaches "The ProductProvider role, e.g., has Read and Write permission only for properties of the submodel Internals. Thus, members of this role are allowed to update the Firmware"."A Device can update the actually measured values within the submodel Operation", "Read permission to all relevant properties can be clustered and reused for multiple roles (i.e., Device and Customer)" , "Using AuthorizationReference reference types on submodels like Operation, Configuration or Maintenance, the contained properties are inheriting the corresponding access rights"; page 432, Requirement 2: Fine-grained authorization on information level. As defined previously, authorization per submodel types and/or instances are required. However, also the elements within a submodel have to be considered with respect to authorization. [4] suggests to decompose the access into the following levels: (1) Global-Level, (2) Element-Level, (3) ElementAccess-Rights-Level, and (4) Range-limited ElementLevel-Access-Rights. The first two levels define if a user has full access to all elements (1) or certain elements (2). Level (3) requires a more fine granular access rights management, defining if a user has specificaccess rights, e. g., to read or write an element (comparable to a file system). Level (4) provides even more detailed access rights, implementing full attributebased access control, including rules such as predefined value ranges for writing a property), and
the controller categorizes the authenticated user as an internal stakeholder or an external stakeholder (Hen: par. [0022], FIG. 2 illustrates an example computer network 200, such as a local network, a cloud computing network, or a combination of networks that may include a set of users 202 such as users of an enterprise, a set of network items 204 such as enterprise resources accessible or accessed by the users 202, a role-based access controller 206 to restrict network access of the network items 204 grounded on roles of users 202 within the enterprise; par. 0023, “In addition, access to network resources can be limited to specific tasks, such as the ability to view, create or modify files. Limiting network access may be applicable for enterprise that have many employees, employ contractors or permit access to third parties, like customers and vendors; ““enterprises can designate whether a user is an end user, an administrator or a specialist user” and controls the access authority to the asset information according to the category of the authenticated user, the asset status, and the asset information authority (Hen: par. 0022; Krueger: par. 0032; Schmitt: page 432, Requirement 1;; page 434, 3.2 Recommended solution; page 432, Requirement 2; Nelaturi: par. 0001).
Regarding claim 13, claim 13 is directed to a method for managing access to asset information performed in a system that manages the asset information of a smart factory associated with the method claimed in claim 1; claim 13 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is similar in scope to claim 4, and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is similar in scope to claim 12, and is therefore rejected under similar rationale.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning` this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
May 16th, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights