DETAILED ACTION
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
INDEFINITENESS — UNCLEAR TRANSITIONAL PHRASE “IS CHARACTERIZED IN THAT”
Independent claim 1 (and dependent claims 2–7 through dependency) uses the phrase “is characterized in that the system includes: …” as the transition into the body of the claim. The phrase “is characterized in that” is not a customary U.S. transitional phrase and does not clearly indicate whether the claim is intended to be open-ended (e.g., “comprising”) or closed (e.g., “consisting of”), thereby rendering the scope unclear.
Applicant is advised to amend the transition to a recognized U.S. transitional phrase (for example, “comprising” or “including”) to clarify claim scope.
INDEFINITENESS — “MODULE / PLATFORM / VIEW” TERMINOLOGY DOES NOT CLEARLY CONNOTE STRUCTURE AND MAY INVOKE 35 U.S.C. § 112(f)
Claims 1–7 repeatedly use functional placeholders such as “business view module,” “record information maintenance module,” “statistical analysis module,” “record information management module,” “system management module,” and “blockchain foundation platform,” and claim 2 further uses “configuration view,” “status view,” “operation view,” and “asset view.”
These terms, as used in the claims, describe what each “module/platform/view” does (i.e., functional results) but do not clearly set forth what each element is (i.e., the structural components, such as at least one processor, memory, and software instructions, or specific hardware circuitry), nor do they clearly define how the functions are implemented. As written, one of ordinary skill cannot determine with reasonable certainty the bounds of the claim because it is unclear what structural limitations (if any) are imposed by each “module/platform/view,” and whether the “module/platform/view” terms are intended to cover any and all means for performing the stated functions.
Applicant is advised to clarify by explicitly reciting structure (for example, “one or more processors and a memory storing instructions that, when executed, cause the one or more processors to…”) and/or by otherwise amending the claim language so the “module/platform/view” elements connote sufficiently definite structure to those of ordinary skill in the art. If applicant intends any of these terms to be interpreted under 35 U.S.C. § 112(f), applicant should ensure the specification provides corresponding structure (including, for computer-implemented functions, sufficient algorithmic disclosure) for performing each claimed function, and should amend accordingly to avoid indefiniteness.
INDEFINITENESS — AMBIGUOUS / RELATIVE LANGUAGE WITHOUT BOUNDARIES
Claims 1–7 include multiple terms of degree, relative scope, or result-oriented statements without objective boundaries, which renders the metes and bounds unclear. Non-limiting examples include:
In claim 1, “different dimension” and “different management dimensions” do not specify what dimensions are included/excluded or how “dimension” is defined in the context of the claimed system.
In claim 1, “could displayed in table, charts and other ways” includes “other ways,” which lacks definitional boundaries as to what additional display forms are encompassed and whether any constraints apply.
In claim 6, “optimized by the blockchain structure to realize flexible uploading” uses “optimized” and “flexible” without defining what is optimized (e.g., bandwidth, throughput, storage cost, latency), what degree of improvement is required, and what constraints define “flexible uploading.”
In claim 6, “whether or not to upload the data is selected at different business stages according to user requirements” lacks objective constraints defining which “user requirements” are relevant, how those requirements are captured, and what selection criteria govern the upload decision.
In claim 7, “information technology” is overly generic and does not meaningfully limit the claim because it is not a term with a clear boundary in this context. Claim 7 further uses “structural analysis technology,” “target data identification,” “serialization processing,” and “correlation knowledge” without defining the operative boundaries of each term in a manner that would allow a skilled artisan to determine claim scope with reasonable certainty.
Applicant is advised to amend the claims to replace relative/result terms with objective technical limitations (for example, identifying specific data structures, indexing techniques, extraction rules, model types, or decision criteria), or to otherwise define the ambiguous terms in the claims so that scope is clear.
INDEFINITENESS — ANTECEDENT BASIS / UNCLEAR REFERENTS
Claim 2 states “the record information view includes a configuration view, a status view, an operation view, and an asset view.” However, in claim 1, “record information view” is mentioned only as something the “business view module” allows access to, and is not clearly introduced as a structural element of the system with clear boundaries. As a result, it is unclear whether “record information view” is (i) part of the “business view module,” (ii) a separate component, or (iii) merely a user interface concept with no structural limitation.
Claim 2 also introduces multiple entities (“host enterprise,” “subway company,” “operating company,” “subject company”) in a manner that makes it unclear whether these are different entities, the same entity under different labels, or required distinct parties. This uncertainty impacts claim scope because the claims appear to require normalization across “different host enterprises” and access control across “different operating companies,” but the boundaries of those entities are not defined.
Applicant is advised to amend the claims to provide clear antecedent basis and consistent naming for the relevant system components and organizational entities.
INDEFINITENESS — INCONSISTENT TERMINOLOGY FOR LIFE-CYCLE STAGES
Claim 1 defines “stages” as “procurement, operation, renewal and reconstruction,” while claim 2 describes “procurement, operation, renewal and transformation,” and claim 6 describes lifecycle phases including “project establishment, design liaison, supervision and manufacture, check and acceptance, operation, and scrapping.” The inconsistent terms “reconstruction” versus “transformation” and the differing stage lists create ambiguity as to what lifecycle stages are required by the claims and whether the system must support all described stages or only a subset.
Applicant is advised to amend for consistency (for example, using a single defined set of lifecycle stages throughout the claims) and to clarify whether the stages are exhaustive or exemplary.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 7 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
CLAIM 7: REJECTED UNDER 35 U.S.C. § 112(a) (ENABLEMENT)
Claim 7 is rejected under 35 U.S.C. § 112(a) because the specification, while describing the goal of forming a knowledge base from Excel/Word/PDF files using full-text search and structural analysis, does not set forth sufficient detail to enable one of ordinary skill in the art to make and use the full scope of claim 7 without undue experimentation.
In particular, claim 7 encompasses (among other things) “target data identification,” “serialization processing,” “association with unstructured data,” “construction of query indexes,” gradual formation of a “knowledge base,” and providing “maintenance guidance and repair program … in the form of correlation knowledge.” The disclosure provides high-level functional descriptions of these outcomes but does not provide commensurate implementation detail (for example, specific extraction/normalization rules, document parsing and structural feature definitions, entity resolution/linking logic, index schema, correlation/association logic, knowledge representation format, and the criteria/rules/models used to generate “maintenance guidance” and “repair program” outputs).
Applicant is advised that enablement may be overcome by narrowing claim 7 to specific, disclosed techniques and data structures, and/or by amending the specification to include additional technical detail sufficient to support and enable the claimed knowledge-base formation and guidance generation across the full claim scope.
LIST OF REFERENCES USED
REFERENCE 1
CN114154951A — “Railway freight car operation management system.”
REFERENCE 2
US20200184739A1 — “Block chain based system and method for improving aircraft maintenance services.”
REFERENCE 3
US11055703B2 — “Smart contract lifecycle management.”
REFERENCE 4
US20180374091A1 — “Method and System for Blockchain-Based Combined Identity, Ownership, Integrity and Custody Management.”
REFERENCE 5
US20160328890A1 — “System and Method for Automotive Diagnostic Tool Data Collection and Analysis.”
REFERENCE 6
US20090228777A1 — “System and Method for Search.”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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–6: REJECTED UNDER 35 U.S.C. § 103 OVER REFERENCE 1 IN VIEW OF REFERENCE 2, AND IN FURTHER VIEW OF REFERENCE 3, REFERENCE 4, AND REFERENCE 5
The combination is applied as follows. Reference 1 is relied upon as the primary teaching of a rail-vehicle operation/maintenance information management system with (i) integrated management of design/configuration and maintenance technical information and (ii) maintenance service process control, data collection, parts definition/management, and a maintenance knowledge base (system 100; subsystems 101, 102; SBOM module; IETM module; work card module; spare part definition module; maintenance knowledge management module; maintenance process management module; fault knowledge base).
Reference 2 is relied upon for teaching use of a blockchain network and blockchain digital ledger for storing maintenance data/tasks and time-stamped activities distributed across multiple organizations (maintenance workflow diagram 100; Blockchain Network 10; digital ledger 15; rules 12; maintenance activity 22; server 30; cloud data repository 20; app 60; mobile device 40).
Reference 3 is relied upon for teaching deployment and upgrading/updating of smart contracts in a blockchain environment (smart contract configurator; “Deploy”/“Upgrade”; smart contract period DS 218; client node 108; smart contract request 126; consensus node execution; recording results on blockchain).
Reference 4 is relied upon for teaching system roles/permissions/authority for blockchain applications via role-based access control tied to smart contracts and resources (smart contract 750; state variables 752; functions 754; contract owner 762; application owner 770; users 764/768/772/774; multiple smart contracts 756/776; state variables 758/778; functions 760/780).
Reference 5 is relied upon for teaching statistical analysis outputs displayed in text/graphics dashboards for service/diagnostic records (diagnostic analysis system 104; summarized reports; dashboard overview; retrieval and display of detailed service records).
────────────
A subway vehicle electronic record system based on blockchain technology is characterized in that the system includes: A business view module which allows the users with different functions to access record information view with different dimension; A record information maintenance module, which is used to add, modify and search data information about subway vehicle records according to different stages and different functions as well as allow the personnel of the responsible departments to access the maintenance function for the vehicle record information, for which purpose the “stages” refers to procurement, operation, renewal and reconstruction, and the “functions” refers to maintenance, repair and assets; A statistical analysis module, in which the vehicle information could be searched, sorted out and analyzed from different management dimensions, for data statistical analysis related to vehicle, which could displayed in table, charts and other ways; Record information management module, which is for the management and maintenance of subway vehicle basic information, parts, data collection, suppliers and data security; for this purpose, the “subway vehicle basic information” includes subway vehicle models, subway vehicle configuration, subway vehicle grouping, etc.; A system management module, which is for the management of organizational system, personnel, system roles, authority and log monitoring; A blockchain foundation platform, which is for the visual deployment, upgrading, and updating of smart contracts, as well as the uploading the record data to blockchain and storage and verification of record data.
CLAIM 1 — LIMITATION-BY-LIMITATION ANALYSIS
Claim 1 requires a rail-vehicle electronic record system.
Reference 1 teaches a rail-vehicle operation management system 100 for railway wagons, including a technical information management subsystem 101 and a service process management subsystem 102, where subsystem 101 manages design information and maintenance technical information and subsystem 102 controls the maintenance service process and collects maintenance process information (system 100; subsystems 101, 102). This teaches an electronic record/management system for rail vehicles, because design information, maintenance technical information, maintenance process information, and supporting technical content (manuals, work cards, spare part atlas) are maintained and used electronically by the system 100.
Claim 1 requires the system to be “based on blockchain technology.”
Reference 2 teaches a maintenance workflow diagram 100 in which maintenance activities are implemented via an app connected to a Blockchain Network 10, with maintenance data and maintenance tasks stored in a blockchain digital ledger 15 (workflow diagram 100; Blockchain Network 10; ledger 15; app 60). Reference 2 further teaches that time-stamped maintenance activities and checks are stored in the ledger 15. This teaches a maintenance record system based on blockchain technology.
In the combined system, Reference 1 provides the rail-vehicle record-management functionality, and Reference 2 provides the blockchain ledger layer used to store/verify at least selected maintenance records and tasks (ledger 15) for improved integrity, cross-organization coordination, and time-stamped traceability (Blockchain Network 10; ledger 15).
Claim 1 requires “a business view module which allows the users with different functions to access record information view with different dimension.”
Reference 1 teaches that information content is categorized and organized in a structured manner and stored in a content management system information base, and that different display modes are produced for the same data set by creating a style template (content management system information base; different display modes via style template). Reference 1 further teaches field task viewing interfaces and maintenance operation guidance (service process management subsystem 102 and its interface for outfield task viewing; maintenance operation guidance; IETM-based guidance). These teachings collectively support a “business view module” because (i) the system presents different display modes for the same underlying data and (ii) the system supports different user work contexts (technical information management vs. service process management; outfield task viewing vs. technical content management).
Additionally, Reference 4 teaches role-based access control to restrict access to authorized users, where different users have access to different smart contract resources (smart contract 750; users 764/768; contract owner 762; roles/policies tied to state variables 752 and functions 754). This teaches “users with different functions” (different roles) accessing different views/dimensions of the same record information depending on role/authorization.
Accordingly, the combination teaches a business view module providing differentiated access and presentation of record information to users with different functions/roles (Reference 1 structured information base and different display modes; Reference 4 role-based access controls for differential access).
Claim 1 requires “a record information maintenance module” used to “add, modify and search” data information about subway vehicle records, according to different stages and different functions, with “stages” including procurement, operation, renewal and reconstruction, and “functions” including maintenance, repair and assets.
Reference 1 teaches that the technical information management subsystem 101 performs systematic management of maintenance service technical data, converts design information into service information, and provides management functions including version management and engineering change management for maintenance BOM and related technical information (subsystem 101; SBOM creation/management; version management; engineering change management). Managing versions and engineering changes is a “modify” function applied across lifecycle stages (including renewal/reconstruction activities reflected by engineering changes).
Reference 1 further teaches that the service process management subsystem 102 includes a maintenance process management module that covers the whole process of service, records maintenance data in a standardized manner, and includes resource scheduling and resource consumption record (subsystem 102; maintenance process management module; standardized maintenance data recording; resource scheduling/consumption record). This teaches adding and maintaining records during operation and maintenance/repair stages, as well as searching/retrieving relevant work cards and manuals for a given service requirement (work card retrieval and issuing; IETM calling for maintenance guidance).
Reference 2 teaches that maintenance activities 22 are configured by rules 12 and that maintenance data and tasks are stored in the digital ledger 15, with sequences of activities delivered to different personnel through app 60 (activity 22; rules 12; ledger 15; app 60). This supports “add” and “modify” of maintenance-related record items (adding time-stamped activity records, updating task status, etc.) and “search”/viewing of assigned activities.
Accordingly, the combined teachings provide a record information maintenance module in which vehicle record information is added, updated (including versioning and engineering changes), and retrieved for different lifecycle stages (design/procurement-related design/service information conversion; operational maintenance process recording; engineering change for renewal/reconstruction) and for different functions (maintenance/repair functions explicitly taught; asset-related resource scheduling/consumption records taught, and asset views are further supported by the ledger and reporting teachings below).
Claim 1 requires “a statistical analysis module” in which vehicle information is searched, sorted, and analyzed from different management dimensions, displayed in tables/charts.
Reference 5 teaches that a diagnostic analysis system 104 provides summarized reports over a time period and that reports include text and graphics providing a “dashboard” overview with a user interface enabling retrieval and display of detailed service records on demand (system 104; summarized reports; dashboard; retrieval/display of service records). This teaches statistical analysis of vehicle-related operational/maintenance data and display in graphics and textual formats (tables/charts/dashboards).
In the combination, the record data managed by Reference 1 and the blockchain-stored task/activity data of Reference 2 are suitable inputs to the analysis/reporting functions of Reference 5 (system 104), thereby teaching the claimed statistical analysis module.
Claim 1 requires a “record information management module” for management and maintenance of subway vehicle basic information, parts, data collection, suppliers, and data security, where basic info includes models/configuration/grouping.
Reference 1 teaches configuration/structure management via SBOM creation/management based on EBOM and maintenance BOM management with version and engineering change management (SBOM module; EBOM-to-SBOM; maintenance BOM; version management; engineering changes). This teaches “subway vehicle configuration” management (vehicle configuration hierarchy and change management).
Reference 1 teaches spare part definition and management via SBOM-based management and spare part atlas linked to design/loading information (spare part definition/management module; SBOM; spare part album linked to design/loading info). This teaches parts management.
Reference 1 teaches vehicle data acquisition and feedback via portable maintenance auxiliary terminal (PMA) and further includes an Internet of Things intercommunication and health prediction module (PMA; vehicle data acquisition/feedback; IoT intercommunication module). This teaches data collection management.
Reference 1 teaches summarizing information from OEMs and suppliers, and exchanging service/part information with other enterprise systems (maintenance knowledge management module; information from OEMs/suppliers/service centers/customers; exchanging service information/part information). This supports supplier-related information management.
For data security, Reference 2 teaches storing maintenance data/tasks on a blockchain digital ledger 15 (ledger 15) and Reference 4 teaches access control and permissions via roles/policies (smart contract 750; roles/policies; different user access), thereby teaching security of data access and tamper-resistance/traceability for stored records.
Claim 1 requires a “system management module” for organizational system, personnel, system roles, authority, and log monitoring.
Reference 4 teaches defining roles and policies controlling access to blockchain applications and smart contracts, with different users having different permissions (roles/policies; smart contract 750; contract owner 762; application owner 770; users 764/768/772/774). This teaches system roles and authority management.
Reference 2 teaches time-stamped maintenance activities stored in the digital ledger 15 and sequences assigned to personnel (ledger 15; time-stamped activities; assignment to various personnel; app 60 display). This teaches log/recording of actions and status in a tamper-evident ledger, consistent with log monitoring.
Reference 1 teaches maintenance work card management with authority and signature processes (work card management module; authority; examination/signature process), which further supports personnel/authority management in the system context.
Thus, the combination teaches system management including personnel/role/authority and monitoring of system actions via logged activity records (ledger 15).
Claim 1 requires a “blockchain foundation platform” for visual deployment/upgrading/updating of smart contracts, uploading record data to blockchain, and storage/verification of record data.
Reference 2 teaches uploading/storing maintenance data and tasks in a blockchain digital ledger 15 (ledger 15), thereby teaching uploading record data to blockchain and storing record data on-chain.
Reference 3 teaches smart contract lifecycle management including processing “Deploy” and “Upgrade” configuration requests, running the smart contract on a consensus node, and recording transaction results on the blockchain (Deploy/Upgrade; smart contract configurator; DS 218; client node 108; smart contract request 126; consensus node execution). This teaches deployment and upgrading/updating of smart contracts and execution within a blockchain platform.
Accordingly, the combined teachings provide a blockchain foundation platform with smart contract management and on-chain record storage/verification (ledger 15, blockchain recording of results).
MOTIVATION STATEMENT (CLAIM 1)
It would have been obvious to a person of ordinary skill in the art, at the time of the invention, to modify the rail-vehicle operation/maintenance information management system 100 of Reference 1 to incorporate blockchain-based storage/verification for at least selected maintenance/record events as taught by Reference 2 (Blockchain Network 10; digital ledger 15) because Reference 1 expressly addresses multi-party information flows (design/maintenance technical information and service process information) and is directed to supporting maintenance service, while Reference 2 teaches that distributing time-stamped maintenance activities across multiple organizations using a blockchain ledger improves integrity, traceability, and coordinated execution across personnel and organizations. The combination is a predictable use of known blockchain ledger technology to improve trust and tamper-resistance of maintenance/record data across multiple stakeholders.
It would also have been obvious to incorporate smart contract deployment/upgrade mechanisms as taught by Reference 3 because once business logic and access control for the blockchain layer is implemented in smart contracts, a practical system requires deployment and upgrade management (Deploy/Upgrade; DS 218) to support maintenance of the system over time.
It would further have been obvious to implement role/authority controls as taught by Reference 4 because Reference 1 already contemplates controlled access (authority/signature management for work cards) and operational use by different stakeholders, and Reference 4 teaches role-based access control tied to smart contracts as a known approach to enforce authorization in blockchain applications.
It would further have been obvious to incorporate statistical dashboards and report generation as taught by Reference 5 because maintenance/operation systems routinely benefit from summarizing large volumes of service records into management-consumable reports and dashboards (system 104; dashboard; summarized reports), and such reporting is a predictable enhancement once electronic records are collected and stored.
A person of ordinary skill would have had a reasonable expectation of success because each reference teaches compatible, computer-implemented modules (record management; blockchain ledger storage; smart contract lifecycle management; role-based authorization; analytics dashboards) and their integration involves routine software engineering (linking stored record data to reporting and permission layers) without changing the fundamental operation of the underlying systems.
──────────── 2. A subway vehicle electronic record system based on blockchain technology as claimed in claim 1 is characterized in that the record information view includes a configuration view, a status view, an operation view, and an asset view; The said configuration view, which adopts the vehicle management manner of the host enterprise to uniformly standardize the names of vehicle components of different host enterprises, determine a series of unified subway company's “label” for the vehicle component names, establish an arbitrary level of product decomposition structure to realize the refined and complete management view of the composition of the subway vehicle, as well as the substitution and alteration of the key components of the vehicle information; The said status view, which could view the technical documents, maintenance/conservation specifications, spare parts/parts, and current status of the operating vehicles and major components, based on the functional structure of the daily maintenance of the operating company and available authority of the corresponding subway vehicles and vehicle components data granted by different operating companies; The said operation view, which is used to warn, monitor in real time and search the history data based on the overhaul operation data, fault information data and operation information data of subway vehicle and major components published by different operating companies from the management perspective of operating companies; The said asset view, which realizes the whole process of closed-loop management for the vehicle assets from the company's subway vehicle procurement, operation, renewal and transformation, vehicle parts and components of the spare parts/pieces of the procurement, warehousing, collocation, change, maintenance, transfer to the renewal and transformation of the disposal dimension to show of spare parts/pieces of vehicle parts and components from the perspective of assets management department of subject company.
CLAIM 2 — LIMITATION-BY-LIMITATION ANALYSIS
Claim 2 requires that the record information view includes four views: configuration view, status view, operation view, and asset view.
Reference 1 teaches that different display modes are made for the same data set stored in an information base through creating a style template, and documents can be produced for different delivery platforms (different display modes via style template; PDF/Web delivery). This teaches a system presenting the same underlying record information through multiple views/modes.
Reference 1 further teaches multiple functional modules spanning configuration/technical data (SBOM creation and management module; IETM module), parts definition/management (spare part definition and management module), and service process execution (maintenance process management module), which inherently supports presenting data via different task-oriented views (technical/configuration vs. service execution vs. parts/support).
Claim 2’s “configuration view” requires standardizing component names across different enterprises, defining unified labels, establishing a product decomposition structure, and managing substitution/alteration of key components.
Reference 1 teaches SBOM creation and management based on EBOM and that the SBOM maintenance configuration adds maintenance units, includes functional descriptions and parts catalog illustrations, and that SBOM management includes version management and engineering change management of the maintenance BOM and related technical information (SBOM module; EBOM-to-SBOM; SBOM maintenance configuration; parts catalog illustrations; version management; engineering changes). This teaches a product decomposition structure of the vehicle and its systems/components (e.g., EBOM including systems such as body system, bogie system, brake system), and managing changes to that structure (engineering changes; version management). Such BOM-based structuring is a known approach for standardizing component naming and labeling across organizations because the BOM provides a unified taxonomy for parts and assemblies.
Accordingly, Reference 1 teaches the substance of the configuration view: a structured hierarchical decomposition (EBOM/SBOM), standardized maintenance parts cataloging, and management of substitutions/alterations via engineering change/version management.
Claim 2’s “status view” requires viewing technical documents, maintenance/conservation specifications, spare parts/parts, and current status of operating vehicles/major components, based on daily maintenance functional structure and authority.
Reference 1 teaches IETM compilation/management and maintenance work cards used as technical bases for field maintenance, and retrieval/issuing of relevant service work cards according to field service requirements (IETM module; work card management module; retrieving/issuing work cards; maintenance guidance). Reference 1 teaches spare part definition/management module and spare part atlas linked to design/loading information (spare part module). These teach viewing technical documents and parts information.
Reference 1 also teaches that, in a management phase, access to information content is managed (management phase; access management) which supports authority-based viewing.
Therefore, Reference 1 teaches a status-oriented view enabling authorized users to view technical documents/specifications and parts information relevant to current vehicle service context.
Claim 2’s “operation view” requires warning/real-time monitoring/history search based on overhaul operation data, fault information data, and operation information data, from an operating company perspective.
Reference 1 teaches that the service process management subsystem 102 includes an Internet of Things intercommunication and health prediction module and a fault knowledge base (subsystem 102; IoT intercommunication/health prediction module; fault knowledge base). These teachings support monitoring/health prediction (warning) and fault information.
Reference 1 further teaches maintenance process management covering problem positioning and service execution and recording standardized maintenance data, and using a portable maintenance auxiliary terminal to perform vehicle data acquisition and feedback (maintenance process management; problem positioning; PMA vehicle data acquisition/feedback). These teach collecting and reviewing operational/service data and maintaining history.
Accordingly, Reference 1 teaches a view for operational monitoring/warning and accessing historical maintenance/fault/operation information.
Claim 2’s “asset view” requires closed-loop asset management across procurement, operation, renewal/transformation, spare parts procurement/warehousing/collocation/change/maintenance/transfer/disposal, from an asset management department perspective.
Reference 1 teaches SBOM-based spare part definition and management, association between spare part atlas and design/loading information, and that design changes propagate to spare part album/loading information (spare part module; SBOM; change response). Reference 1 also teaches maintenance process management including resource scheduling and resource consumption record (resource scheduling; consumption record). These teachings support tracking parts/resources across warehousing/use and recording consumption.
Further, Reference 2 teaches that maintenance data and tasks are stored in a blockchain digital ledger 15 with time-stamped records (ledger 15), which supports auditability of asset-related events (procurement records, replacement events, transfers, disposal records) in a closed-loop manner.
Thus, the combination teaches closed-loop traceable management of vehicle/parts assets across lifecycle events, with on-chain time-stamped records for verification (ledger 15) and BOM-based parts/structure management and maintenance resource tracking (SBOM/parts modules; resource consumption record).
MOTIVATION STATEMENT (CLAIM 2)
It would have been obvious to provide multiple role- and task-oriented views (configuration/status/operation/asset) in the combined system of claim 1 because Reference 1 explicitly teaches presenting the same data set in different display modes via style templates and supports different user workflows (technical information management vs. service process execution). Once a system serves multiple stakeholders (engineering, maintenance, operations, logistics/parts), it is a predictable design choice to organize user interfaces into separate views aligned to configuration management, current technical status, operational monitoring, and asset lifecycle tracking to improve usability and reduce errors.
It would have been further obvious to implement the configuration view using BOM/SBOM structures and engineering change/version management taught by Reference 1 because that is a known, reliable mechanism for standardized component naming and hierarchical decomposition across organizations.
It would have been further obvious to implement the asset view as a closed-loop lifecycle process (including parts procurement/warehousing/use/transfer/disposal) and to record the associated events in the blockchain ledger 15 taught by Reference 2, because blockchain’s auditability and time-stamping are commonly applied to track ownership, custody, and lifecycle events in multi-party environments, and the system already tracks parts and resource consumption.
A person of ordinary skill would have had a reasonable expectation of success because these views are presentations of already-collected data (SBOM/parts/work cards/fault data/ledger events) and can be implemented via routine UI and database design.
──────────── 3. A subway vehicle electronic record system based on blockchain technology as claimed in claim 1 is characterized in that the said record information includes vehicle record information, components and parts information, operation data information, and maintenance/repair information; The said vehicle record information, which realizes the record information maintenance and management of structured and non-structured data such as basic data, state information, repair and maintenance information, spare parts and components, and other structured and unstructured data of the subway vehicle by providing the vehicle record information query and maintenance function for the operating company, according to the norms and requirements of the configuration management of the subway vehicle, and realizes the change of the subway vehicle, the key components and the historical information traceability through the record version control; comprehensively displaying data information such as basic information, fault information, overhaul information, status information, transformation information, key parts information, equipment data, etc. of subway vehicles; The said parts information, which realizes the query and maintenance of the inventory, storage unit, quantity and other information of the spare parts and components, and replacement parts of the vehicle parts, effectively utilizing the life of the parts and reducing the inventory level, and at the same time realize the full life cycle management of the key parts, as well as realizes the reverse tracing of the information in the stages of overhauling, operation, production and design by serial number in case of a problem; The said operation data information, which realizes the reporting and query function of the operation status log information of the subway vehicle and key components, control system and train-to-ground communication system and other information; The said maintenance/repair information, which realizes the reporting and query of operation data of subway vehicles and key components.
CLAIM 3 — LIMITATION-BY-LIMITATION ANALYSIS
Claim 3 requires that record information includes (i) vehicle record information, (ii) components/parts information, (iii) operation data information, and (iv) maintenance/repair information.
Reference 1 teaches a system 100 integrating design information and maintenance technical information (subsystem 101) with maintenance service process control and information collection (subsystem 102), and explicitly includes modules for spare part definition/management and maintenance knowledge management, as well as a maintenance process management module that records maintenance data in a standardized manner and uses a portable maintenance auxiliary terminal for vehicle data acquisition and feedback (system 100; subsystems 101/102; spare part module; maintenance knowledge management module; maintenance process management module; PMA vehicle data acquisition/feedback). These teachings collectively correspond to the claimed record information categories: vehicle records (design + maintenance technical info and service process records), parts information (spare part definition/management), operation data (vehicle data acquisition and IoT intercommunication/health prediction), and maintenance/repair information (maintenance process tasks, work cards, guidance, completion records).
Claim 3’s “vehicle record information” requires maintenance/management of structured and unstructured data including basic data, state info, repair/maintenance info, spare parts, and traceability via record version control; comprehensive display of fault/overhaul/status/transformation/key parts/equipment data.
Reference 1 teaches that manuals and documents are categorized and organized in a structured manner in a content management system information base and that documents consist of text, lists, tables, graphics, and images (structured and unstructured content) (content management system information base; structured organization; mixed content types). Reference 1 further teaches SBOM management includes version management of technical content and engineering changes of the maintenance BOM and related technical information (version management; engineering change management), providing traceability of configuration changes over time.
Reference 1 further teaches that maintenance process management covers problem positioning, service execution, and standardized maintenance data recording (problem positioning; standardized maintenance data), which corresponds to fault/repair/overhaul records. Reference 1 further teaches exchanging service information and part information across organizations (knowledge management module), supporting comprehensive record aggregation.
Thus, Reference 1 teaches maintaining and displaying vehicle record information including configuration/version traceability and fault/maintenance-related records.
Claim 3’s “parts information” requires query/maintenance of inventory, storage unit, quantity, replacement parts; effective utilization of part life, reduce inventory; full life cycle management of key parts; reverse tracing across overhaul/operation/production/design by serial number.
Reference 1 teaches spare part definition and management based on SBOM, and association between spare part atlas and design/loading information with responsiveness to design changes (spare part module; SBOM; association with design/loading info; change response). This supports traceability between parts and design configuration.
Reference 1 also teaches maintenance process management including resource scheduling and resource consumption record (resource scheduling; consumption record), which supports tracking inventory usage and replacement events.
Reference 2 teaches that maintenance data and checks are stored in a blockchain digital ledger 15 with time-stamped activities (ledger 15; time-stamped activities). Applying ledger records to parts replacement and custody events provides a traceable lifecycle history for key parts and supports reverse tracing when a problem occurs.
Accordingly, the combination teaches lifecycle tracking and traceability for parts information, including usage/replacement records and linkage to design configuration information. To the extent “by serial number” is not explicitly expressed in Reference 1, it would have been an obvious implementation detail because parts catalogs/atlases and maintenance tracking commonly use unique identifiers for parts, and blockchain ledger entries are routinely keyed to unique identifiers to ensure correct traceability.
Claim 3’s “operation data information” requires reporting/query of operation status log information of vehicle and key components, control system, train-to-ground communication system and other information.
Reference 1 teaches an IoT intercommunication and health prediction module and a portable maintenance auxiliary terminal for vehicle data acquisition and feedback (IoT intercommunication module; PMA vehicle data acquisition/feedback). These teach collecting operation status data from vehicle systems/components and making such data available in the system for retrieval.
Reference 2 teaches storing aircraft flying hours, checks, and maintenance activities in the ledger 15 (ledger 15; flying hours/check activities/dependencies). This teaches operation status logging stored in an immutable ledger for later query.
Thus, the combination teaches reporting/query of operation status logs for the vehicle and key systems, including communications-related status information in the broader sense of intercommunication data (IoT intercommunication module) and logged operational metrics (ledger 15).
Claim 3’s “maintenance/repair information” requires reporting/query of operation data of vehicles and key components.
Reference 1 teaches maintenance process management (requirements, problem positioning, service execution, completion recording) and explicitly records maintenance data in a standardized manner and calls IETM for guidance (maintenance process management module; standardized maintenance data recording; IETM-based maintenance guidance). These are maintenance/repair information records that can be queried and reported.
Reference 2’s ledger 15 records time-stamped activities and checks, enabling retrieval and reporting of maintenance/repair history.
Accordingly, the combined teachings meet the limitation.
MOTIVATION STATEMENT (CLAIM 3)
It would have been obvious to organize the system’s stored information into the specific categories of vehicle records, parts records, operation logs, and maintenance/repair records because Reference 1 already teaches integrated management of design/configuration information, service technical information, maintenance process records, and spare parts information, and further teaches structured information bases for documents and maintenance knowledge management. Categorizing record information is a predictable database and UI organization step to support efficient querying, reporting, and permissioning.
It would have been further obvious to use blockchain ledger storage (Reference 2, ledger 15) for at least selected subsets of these records (maintenance events, key component replacement events, operational logs) because doing so provides tamper-evident traceability, which is particularly beneficial for fault investigations and lifecycle tracking.
A person of ordinary skill would have had a reasonable expectation of success because the categories correspond to existing modules (SBOM/parts modules, maintenance process module, IoT data acquisition, ledger records) and implementing category labels and identifiers is routine.
──────────── 4. A subway vehicle electronic record system based on blockchain technology as claimed in claim 1 is characterized in that the data queried and analyzed by the said statistical analysis module include an asset ledger, a vehicle ledger, a parts ledger, and a statistical statement.
CLAIM 4 — LIMITATION-BY-LIMITATION ANALYSIS
Claim 4 requires that the statistical analysis module queries/analyzes data including an asset ledger, a vehicle ledger, a parts ledger, and a statistical statement.
Reference 5 teaches generation of summarized reports for diagnostic/service data over time and that such reports provide dashboard overviews and allow retrieval/display of detailed service records (system 104; summarized reports; dashboard; service records). These teachings directly support a “statistical statement” and analysis outputs derived from stored service/vehicle data.
Reference 2 teaches a blockchain digital ledger 15 storing aircraft flying hours, checks, and maintenance activities (ledger 15; flying hours/checks/activities). This teaches a “vehicle ledger” (ledger of vehicle operation/maintenance events) and supports ledger-like tracking of parts replacement and maintenance activities.
Reference 1 teaches spare part definition/management and maintenance process management including resource consumption record (spare part module; maintenance process management; resource consumption record). These teachings correspond to a “parts ledger” (inventory/usage/replacement history) and “asset ledger” (resource consumption/asset-related tracking records) as routine ledger structures in an enterprise maintenance/operations management system.
Accordingly, in the combined system, (i) ledger 15 provides a tamper-evident vehicle/maintenance ledger, (ii) SBOM/parts management plus resource consumption recording provides parts and asset ledger data sources, and (iii) the analysis/reporting functions of Reference 5 produce statistical statements.
MOTIVATION STATEMENT (CLAIM 4)
It would have been obvious to implement the statistical analysis module so that it queries/analyzes ledger-structured datasets (asset ledger, vehicle ledger, parts ledger) because Reference 5 teaches summarizing and reporting diagnostic/service records over time via dashboards, and such reporting is predictably implemented by aggregating underlying records into ledger-like tables keyed by asset/vehicle/part identifiers.
It would have been further obvious to treat blockchain ledger 15 records (Reference 2) as a “vehicle ledger” and to generate corresponding parts/asset ledgers from the parts management and resource consumption records already taught by Reference 1, because ledger-based aggregation is a conventional way to support the very dashboards and summarized reports described in Reference 5.
A person of ordinary skill would have had a reasonable expectation of success because ledger tables are standard database constructs and the system already maintains the source events needed to populate them (maintenance events, parts management events, resource consumption events, operational logs).
──────────── 5. A subway vehicle electronic record system based on blockchain technology as claimed in claim 1 is characterized in that the said record information management module is used for model management, configuration management, vehicle management, grouping management, parts management, supplier management, data collection management, and information setting; The said model management, which covers all models of train information, including train models, names and other key information, and realizes functions such as creation, updating and deletion of models; The said configuration management, which realizes the configuration directory template creation, node creation, label definition, node information project configuration and other management and maintenance functions of subway vehicle, provides the basic directory framework for the information maintenance of the vehicle configuration in the later stage, as well as establishes metadata, data definitions, constrains, data relations for vehicle and provide management function for data, according to the subway vehicle configuration management specification; The said vehicle management, which establishes management configuration and functional configuration for the newly purchased subway vehicles and existing subway vehicles, and defines the vehicle configuration hierarchy, attributable range of hierarchical parts and other functions, according to the subway vehicle configuration management specification; The said grouping management, realizes the detailed information related to all line assignments of the company, which can be associated with multiple conditions such as line assignment, operating company, model, group number, telegraph number, assignment type, assignment date, etc., and displays the maintenance and management functions of line assignments, the current state of the vehicle group, the form of the grouping, and the information of the manufacturing plant; The said parts management, which is used for the construction of parts of the location, type, function and other multi-dimensional management model, and the attributes information in the defining part provides a visual display of the full life cycle of a single piece of maintenance template for the query and maintenance of vehicle record information; The said supplier management, which is for management and maintenance of subway vehicle host manufacturers, parts suppliers and operation and maintenance manufacturers information; The said data collection management, which is for the collection, cleaning, arrangement, management and maintenance of data related to subway vehicle; The said information setting, which is for the management of vehicle maintenance/repair, routing inspection, testing and other types of code table information, as well as maintenance of subway vehicle fault type and fault code relationship.
CLAIM 5 — LIMITATION-BY-LIMITATION ANALYSIS
Claim 5 requires that the record information management module is used for model management, configuration management, vehicle management, grouping management, parts management, supplier management, data collection management, and information setting.
Reference 1 teaches a technical information management subsystem 101 and service process management subsystem 102 (system 100; subsystems 101, 102) and explicitly includes SBOM creation/management (configuration/structure), IETM compilation/management, service card management, spare part definition/management (parts), and service and maintenance knowledge management (knowledge/data). Reference 1 further teaches IoT intercommunication/health prediction and PMA vehicle data acquisition/feedback (data collection). Reference 1 further teaches summarizing information from OEMs and suppliers (supplier-related information). These collectively correspond to the functional scope of a record information management module with multiple sub-management functions.
Claim 5’s “model management” requires managing train models/names and creating/updating/deleting models.
Reference 1 teaches that EBOM/SBOM may be created for specific vehicle models and uses an example indicating a model of a truck (model indicated; EBOM including vehicle systems; SBOM created from EBOM). This teaches model-specific configuration structures and implies managing model identifiers and associated technical content. Managing multiple vehicle models and their associated BOM/technical content is inherent in systems managing fleets across different vehicle types.
Thus, Reference 1 teaches the substance of model management (model-based organization of technical and maintenance information) and it would have been an obvious database management function to provide create/update/delete operations for model entries to maintain the correctness of the system’s model catalog.
Claim 5’s “configuration management” requires directory template creation, node creation, label definition, node information project configuration, and establishing metadata/data definitions/constraints/relations per configuration specification.
Reference 1 teaches SBOM creation and management based on EBOM, adding maintenance units, and SBOM management including establishing and optimizing the maintenance BOM, managing version and engineering changes, and managing electronic workflow and technical information sharing (SBOM module; EBOM-to-SBOM; maintenance BOM optimization; version management; engineering changes; workflow; sharing/exchange). These teachings correspond to building a hierarchical directory/template (BOM hierarchy), defining nodes (assemblies/parts), and managing versions and relations (BOM relations, engineering change management). Reference 1 further teaches structured information elements and a content repository (IETM design/management includes structured information element; content repository), corresponding to metadata and structured definitions associated with configuration information.
Accordingly, Reference 1 teaches the claimed configuration management functions in substance.
Claim 5’s “vehicle management” requires establishing management configuration and functional configuration for newly purchased and existing vehicles, and defining vehicle configuration hierarchy and attributable range of hierarchical parts.
Reference 1’s system 100 manages design information and maintenance technical information for railway wagons and supports maintenance service across lifecycle; it also teaches SBOM configuration and parts cataloging linked to a specific vehicle and loading information (system 100; subsystem 101; SBOM; spare part atlas; association with loading information). These teachings correspond to managing specific vehicles (by associating SBOM and parts/loading information per vehicle) and defining configuration hierarchy and what parts/assemblies belong to the hierarchy.
Thus, Reference 1 teaches vehicle management via per-vehicle configuration/parts association.
Claim 5’s “grouping management” requires managing line assignments, operating company, model, group number, telegraph number, assignment type/date, and displaying state of vehicle group and manufacturing plant info.
Reference 1 teaches a system intended to support maintenance service and data management for rail wagons across service contexts, and it explicitly involves information exchange among multiple parties including OEMs, suppliers, service centers, customers (multi-stakeholder environment) (maintenance knowledge management module; information from multiple parties). In such multi-operator fleet contexts, grouping vehicles by route/line assignment and operator is a conventional fleet management extension for organizing maintenance tasks and assigning resources.
Accordingly, while Reference 1 does not require the specific label “grouping management” as written in claim 5, providing grouping by operator/line/model to support maintenance process management (Reference 1, task distribution platform and resource scheduling) would have been an obvious implementation detail because grouping is a routine way to allocate tasks and track state across a fleet.
Additionally, Reference 2 teaches orchestration of maintenance activities distributed across multiple organizations and personnel (workflow diagram 100; multiple organizations; multiple mobile devices/servers). This further supports grouping/assignment constructs for vehicles and tasks.
Claim 5’s “parts management” requires a multi-dimensional parts management model and visual display of full lifecycle of a single piece, for query/maintenance of vehicle record information.
Reference 1 teaches spare part definition and management based on SBOM, including association between spare part atlas and design/loading information and updating upon design changes (spare part module; SBOM; design/loading association; change response). This teaches multi-dimensional parts relationships (design dimension; loading/installation dimension; spare part atlas dimension) and supports lifecycle traceability.
Reference 2 teaches ledger 15 time-stamped maintenance activities and checks, supporting per-part lifecycle history when applied to replacement/maintenance events (ledger 15).
Thus, the combination teaches parts management with lifecycle visibility and queryability.
Claim 5’s “supplier management” requires management/maintenance of host manufacturers, parts suppliers, and operation/maintenance manufacturers information.
Reference 1 teaches maintenance knowledge management summarizing information from OEMs and suppliers, and exchanging service information/part information with other enterprise systems (maintenance knowledge management module; OEMs; suppliers). This teaches maintaining supplier-related information as part of the system’s information base.
Claim 5’s “data collection management” requires collecting, cleaning, arranging, managing, and maintaining data related to the subway vehicle.
Reference 1 teaches IoT intercommunication and health prediction and vehicle data acquisition/feedback via portable terminal (IoT module; PMA). This teaches collecting operational/maintenance data from vehicles and feeding it into the system.
Reference 6 teaches normalization of uploaded documents (step 2130; blocks 2132, 2134) and segmentation tailored to document portions (block 2136; steps 2138/2140), which are examples of cleaning/arranging/processing unstructured data into usable forms. While Reference 6 is applied explicitly in the rejection of claim 7 below, the same teachings show that “cleaning” and “arrangement” are routine processing steps for collected data in enterprise systems.
Claim 5’s “information setting” requires management of code tables for maintenance/inspection/testing and maintaining fault type/fault code relationships.
Reference 1 teaches maintenance work card management including template, code, type, attribute, version, authority, examination/signature process, change, and technical state management (work card module: template/code/type/attribute/version/authority). Reference 1 also teaches fault knowledge base (fault knowledge base) and maintenance process management including problem positioning (fault-related classification/knowledge). These teachings support code tables and fault code relationships as part of the system’s maintenance knowledge and work card coding infrastructure.
MOTIVATION STATEMENT (CLAIM 5)
It would have been obvious to implement the record information management module as a collection of sub-management functions (model/configuration/vehicle/grouping/parts/supplier/data collection/information setting) because Reference 1 already decomposes the system into multiple management modules (SBOM management, IETM management, work card management, spare part management, maintenance knowledge management, maintenance process management, IoT intercommunication) and explicitly uses structured repositories and version/change management. The claimed sub-functions are predictable administrative decompositions of the same underlying data management problem (managing configuration, maintenance procedures, parts, and stakeholders).
It would have been further obvious to include grouping management (line assignments/operator groupings) because fleet maintenance systems routinely group assets to schedule work and allocate resources, and Reference 1 teaches task distribution and resource scheduling across service requirements, which predictably benefits from grouping vehicles by line/operator/model.
A person of ordinary skill would have had a reasonable expectation of success because these sub-functions involve conventional database CRUD operations, structured hierarchies (BOM), and UI organization, all within the ordinary skill of enterprise system design.
──────────── 6. A subway vehicle electronic record system based on blockchain technology as claimed in claim 1 is characterized in that The data uploading to the blockchain covers the full life cycle of the subway vehicle project establishment, design liaison, supervision and manufacture, check and acceptance, operation, and scrapping, and according to the type of data uploaded to the blockchain, includes the basic vehicle configuration data, vehicle state information, operation and maintenance data, and relevant documents; On-chain contracts include basic function contracts and business contracts, in which the basic function contracts aim to manage and control the permission scheme on each node in the blockchain, user login and other basic functions; the business contracts involve data that need to be uploaded to the blockchain in different business phases, including the contract for registration of project establishment, contract for uploading of project documents, contract for analysis of vehicle configuration, contract for updating of design liaison data, contract for updating supervision on manufacture data, contract for uploading supervision on manufacture documents, and contract for registering leave-factory check and acceptance. The said data uploaded to blockchain is optimized by the blockchain structure to realize flexible uploading, and whether or not to upload the data is selected at different business stages according to user requirements.
CLAIM 6 — LIMITATION-BY-LIMITATION ANALYSIS
Claim 6 requires that data uploaded to blockchain covers full lifecycle stages and includes configuration data, state info, O&M data, and documents.
Reference 1 teaches integrated management of design information and maintenance technical information (subsystem 101), conversion of design information into service information, and structured management of documents with lifecycle stages (management/publishing/delivery/operation phases) with generation and tracking of delivery documents, including conversion of XML documents to formats such as PDF and Web (design information; service information; document lifecycle; PDF/Web delivery). Reference 1 further teaches maintenance service process control and information collection, including vehicle data acquisition and feedback and IoT intercommunication (operation and maintenance data). These collectively correspond to lifecycle-spanning data types: configuration/design data (SBOM/EBOM), operational/state data (IoT and vehicle data acquisition), maintenance data (maintenance process management records), and relevant documents (IETM/work cards/PDF/Web outputs).
Reference 2 teaches that maintenance data and tasks are stored in the blockchain digital ledger 15, with time-stamped activities and checks stored in the ledger 15 (ledger 15). This teaches uploading and storing O&M-related data on-chain.
Accordingly, the combination teaches uploading lifecycle-related configuration/state/O&M/document data to blockchain for integrity and traceability.
Claim 6 requires on-chain contracts including basic function contracts to manage permission scheme on each node, user login, and other basic functions, and business contracts for different business phases including registration of project establishment, uploading project documents, analysis of configuration, updating design liaison data, updating supervision/manufacture data, uploading supervision/manufacture documents, and registering check/acceptance.
Reference 4 teaches role-based access control for blockchain applications, with roles and policies controlling access to blockchain applications and associated smart contracts, and information about roles/policies maintained in a smart contract (roles/policies; smart contract 750; state variables 752; functions 754). This teaches permission schemes implemented through smart contracts (basic function contracts) that control user permissions.
Reference 3 teaches smart contract lifecycle management including deploying and upgrading smart contracts, and that smart contracts receive requests from a client node 108 to execute transactions, with results recorded on the blockchain (Deploy/Upgrade; client node 108; smart contract request 126; consensus node execution; recorded results). This teaches the practical implementation and lifecycle control of on-chain contracts.
Reference 2 teaches that maintenance activity 22 is configured by rules 12 and stored in blockchain ledger 15, and sequences of maintenance activities are assigned to personnel and displayed via app 60 (rules 12; activity 22; ledger 15; app 60). This teaches encoding business process logic (rules/tasks) associated with phases of maintenance execution as on-chain governed activities.
Reference 1 teaches lifecycle and workflow concepts for technical content and maintenance service processes (document lifecycle; electronic workflow; managing engineering changes; managing interfaces; maintenance process management from requirements to execution and record). These teachings provide the business-phase framework for distinct on-chain contracts that correspond to different phases (e.g., design information updates, document uploads, acceptance documentation, and similar workflow checkpoints), even if the exact label “project establishment contract” is not used.
Accordingly, the combination teaches (i) basic on-chain contracts for authorization/permission enforcement (Reference 4) and (ii) deployable/upgradable smart contracts used to implement and manage business workflows and document/data updates across phases (Reference 3 and Reference 1’s workflow/content lifecycle teachings, with Reference 2’s on-chain rules/activity records providing the blockchain workflow pattern).
Claim 6 requires that data uploaded to blockchain is “optimized by the blockchain structure” to realize “flexible uploading,” and whether to upload is selected at different business stages according to user requirements.
Reference 1 teaches that documents can be converted and delivered in different formats (PDF/Web/etc.) and that different display modes are made for the same data set (different display modes; different delivery formats). This teaches selecting representations of data based on stage and use context.
Reference 2 teaches storing maintenance tasks/data in a blockchain ledger 15 and that the app 60 and cloud data repository 20 participate in the workflow (ledger 15; cloud repository 20; app 60). This supports an architecture where not all data must be stored identically on-chain at all times, because an off-chain repository may store bulk data while on-chain records store verification-relevant items (e.g., tasks, checks, or hashes). The concept of stage-dependent selection of what to store on-chain is a known and predictable design choice in blockchain-based enterprise systems to manage performance and cost.
Thus, the combination teaches, or renders obvious, stage-selective uploading of data and flexible handling of on-chain/off-chain representations to achieve practical blockchain deployment.
MOTIVATION STATEMENT (CLAIM 6)
It would have been obvious to extend the blockchain usage of Reference 2 (ledger 15 storing maintenance tasks/data) to cover broader lifecycle data and supporting documents managed by Reference 1 (design/configuration information, technical manuals/work cards, maintenance process records) because the same integrity/traceability benefits apply across the lifecycle of safety-critical rail vehicles, particularly where multiple stakeholders (OEMs, operators, suppliers) contribute and rely on the records.
It would have been further obvious to implement access control and node/user permission schemes as smart contracts (Reference 4, smart contract 750 with role-based policies) because blockchain applications require authorization controls, and Reference 1 already addresses authority/signature workflows for technical content and maintenance cards.
It would have been further obvious to manage deployment and upgrading of those smart contracts using Reference 3’s smart contract configurator (Deploy/Upgrade; DS 218) because a production system must maintain, update, and evolve smart contract logic over time.
It would also have been obvious to make uploading “flexible” and stage-selective because enterprise blockchain deployments commonly avoid putting all bulk documents on-chain at all times due to performance/cost considerations; Reference 2 already uses a cloud data repository 20 alongside ledger 15, indicating a hybrid architecture where certain information can remain off-chain while on-chain records provide verification and traceability.
A person of ordinary skill would have had a reasonable expectation of success because each element (workflow/data management, blockchain ledger storage, smart contract access control, smart contract lifecycle management) is a known, compatible software component and the integration is routine.
CLAIM 7: REJECTED UNDER 35 U.S.C. § 103 OVER REFERENCE 1 IN VIEW OF REFERENCE 2, AND IN FURTHER VIEW OF REFERENCE 3, REFERENCE 4, REFERENCE 5, AND REFERENCE 6
──────────── 7. A subway vehicle electronic record system based on blockchain technology as claimed in claim 1 is characterized in that Based on the files in forms of excel, word, and pdf collected by the users, with the information technology, full-text search technology, and structural analysis technology, the functions of target data identification, serialization processing, association with unstructured data, storage, and construction of query indexes, etc. are realized, and upon satisfying the user's basic query and statistical analysis functions, the knowledge base is gradually formed, and provides users with maintenance guidance and repair program and system support for users in the form of correlation knowledge.
CLAIM 7 — LIMITATION-BY-LIMITATION ANALYSIS
Claim 7 requires files in forms of excel, word, and pdf collected by users.
Reference 6 teaches uploading a full text document such as a Word document in block 2120, uploading a PDF file in block 2122, and uploading PDF drawings in block 2124 (blocks 2120, 2122, 2124). While Reference 6 expressly names Word and PDF in these upload blocks, the same teaching indicates that multiple document forms may be utilized and that user-provided uploads are supported. Excel-type documents are a routine additional document type in the same class of office documents used for records, and the processing pipeline (normalization to a standard format) is not tied to Word/PDF only, making inclusion of spreadsheet files an obvious extension once the system accepts and normalizes user-uploaded office documents.
Claim 7 requires using full-text search technology and structural analysis technology to realize target data identification, serialization processing, association with unstructured data, storage, and construction of query indexes.
Reference 6 teaches normalization of uploaded files into standard formats (step 2130), including converting Word documents to flat text and OCRing PDF files to provide flat text (blocks 2132, 2134). Reference 6 teaches segmenting documents into portions so that full text and drawings are processed differently (block 2136; steps 2138 and 2140). These steps constitute structural analysis of documents (separating sections and extracting text) and enable target data identification (extracting relevant elements), serialization/standardization (conversion to flat text / OCR output), association with unstructured sources (linking OCR-extracted text to original document portions), and storage of processed outputs.
Reference 6 further teaches a search system 7712 that looks at the full text of a document to find keyword matches and may also use relations and metadata for relevance (search system 7712; full text keyword matches; relations/metadata). This supports construction of query indexes and full-text search functionality.
Accordingly, Reference 6 teaches the claimed ingestion/processing/search pipeline and the creation of searchable representations of unstructured documents.
Claim 7 requires that upon satisfying basic query and statistical analysis functions, a knowledge base is gradually formed.
Reference 1 teaches a service and maintenance knowledge management module used for summarizing and managing various information related to maintenance and summarizing information from multiple parties including OEMs, suppliers, service centers, and customers (maintenance knowledge management module; summarizing/managing maintenance-related information). Reference 1 also teaches a fault knowledge base (fault knowledge base) and IETM-based content repositories and structured information bases (content repository; content management system information base). These teachings establish a knowledge base that grows over time as more technical content, service records, and multi-party information are collected.
Reference 5 teaches summarized reports and dashboards derived from accumulated diagnostic/service records over time (system 104; summarized reports), consistent with the system accumulating data and providing analytics.
Thus, the combination teaches forming and expanding a knowledge base as records and documents are collected and processed.
Claim 7 requires providing maintenance guidance and repair program and system support in the form of correlation knowledge.
Reference 1 teaches that the maintenance process management module records maintenance data and calls an interactive electronic technical manual (IETM) to carry out maintenance guidance (maintenance process management module; calling IETM for maintenance guidance). Reference 1 further teaches technical support services for maintenance and repair activities through guided fault isolation expert system (guided fault isolation expert system for maintenance and repair). These teachings correspond to providing maintenance guidance and repair support based on correlated technical content and fault knowledge (IETM + fault knowledge base + maintenance records).
Reference 6’s ingestion and indexing of documents supports correlation knowledge by enabling association between extracted content and indexed records through searchable identifiers and metadata (normalization; OCR; search system 7712). The combination yields a system that correlates documents, indexed terms, maintenance records, and fault knowledge to deliver guidance.
Reference 2 and Reference 4 further support integrity and controlled access to these knowledge artifacts by storing selected records in the blockchain ledger 15 and applying role-based access controls for authorized users.
MOTIVATION STATEMENT (CLAIM 7)
It would have been obvious to incorporate Reference 6’s document ingestion, normalization, OCR, segmentation, and full-text search/indexing pipeline (blocks 2120/2122/2124; step 2130; blocks 2132/2134; block 2136; search system 7712) into the rail-vehicle operation/maintenance management system of Reference 1 because Reference 1 already relies heavily on technical documents and structured repositories (IETM, content management system information base, PDF/Web delivery) and on accumulating maintenance knowledge and fault knowledge over time. Adding full-text indexing and structural analysis to user-collected office documents is a predictable enhancement that improves retrieval of relevant procedures, work cards, and fault isolation content, thereby improving maintenance efficiency.
It would have been further obvious to use the resulting indexed corpus to form an expanding “knowledge base” because Reference 1 explicitly provides a maintenance knowledge management module and fault knowledge base, and Reference 6 provides the technical mechanism to extract, normalize, and index the document content needed to populate and search that knowledge base.
It would also have been obvious to connect this with the statistical analysis/reporting teachings of Reference 5 so that, once indexed records are collected, users can query and analyze the stored information and generate dashboards and reports.
A person of ordinary skill would have had a reasonable expectation of success because the references teach compatible software subsystems (document ingestion/OCR/indexing; maintenance technical content repositories; maintenance process records; knowledge bases; dashboards) and the integration is routine (store normalized text and metadata, build indexes, connect queries to retrieval and guidance outputs).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON C SMITH whose telephone number is (703)756-4641. The examiner can normally be reached Monday - Friday 8:30 AM - 5:00 PM.
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) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Allen Shriver can be reached at (303) 297-4337. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jason C Smith/ Primary Examiner, Art Unit 3613