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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 120as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 17/361,948, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application.
Each of the independent claims claim an aggregator as discussed in paragraphs 87-89 and 93-95 and illustrated in Figure 13. There is no disclosure in the Specification or drawings for the claimed aggregator.
Accordingly, claims 1-20 are not entitled to the benefit of the prior application and have a effective filing date of May 7, 2024 for examination purposes.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-7 recite an apparatus (machine), Claims 8-19 recite a method (process), and Claim 20 recites a computer program product (manufacture), and therefore fall into a statutory category.
Step 2A – Prong 1 (Is a Judicial Exception Recited?):
Referring to claims 1-20, the claims recite a manner of managing entitlement pertaining to assets, which under its broadest reasonable interpretation covers concepts covered under the Certain Methods of Organizing Human Activity grouping of abstract ideas.
The abstract idea portion of the claims is as follows:
(Claim 1) 1. [An apparatus comprising: one or more processors; and a memory coupled to the one or more processors and including a data structure and program code, the data structure including an aggregator having] a plurality of workflow parameter fields and an actionable event entity, [and the program code being configured so that, when executed by the one or more processors, the program code causes the apparatus to:]
(Claim 8) A method, comprising: defining [a data structure including an aggregator having] a plurality of workflow parameter fields [and an actionable event entity];
(Claim 20) [A computer program product comprising: a non-transitory computer-readable storage medium; and program code stored on the non-transitory computer-readable storage medium that, when executed by one or more processors, causes the one or more processors to:] define [a data structure including an aggregator having] a plurality of workflow parameter fields [and an actionable event entity]; receive an alarm based on data [from an IoT device]; parse the alarm into one or more parameters; update a value of each workflow parameter field [of the aggregator] that corresponds to one of the one or more parameters; determine if the alarm is actionable based on the values in the workflow parameter fields [of the aggregator]; and in response to the alarm being actionable, [using the actionable event entity to] generate an actionable event that defines a response to the alarm.
Where the portions not bracketed recite the abstract idea.
Here the claims recite concepts performed in Certain Methods of Organizing Human Activity in particular managing personal behavior or relationships or interactions between people (including following rules or instructions), but for the recitation of generic computer components. In the present application concepts reciting a manner of managing entitlements pertaining to assets. (See paragraphs 2, 4, and 6).
If a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in managing personal behavior or relationships or interactions between people (including following rules or instructions), it falls under the Certain Methods of Organizing Human Activity grouping of abstract ideas. See MPEP 2106.04.
Step 2A-Prong 2 (Is the Exception Integrated into a Practical Application?):
The examiner views the following as the additional elements:
An apparatus. (See paragraph 75)
One or more processors. (See paragraph 76)
A memory. (See paragraph 76)
A data structure. (See paragraphs 84 and 87 and Figure 13)
An aggregator. (See paragraph 87)
Program code. (See paragraphs 81-82)
An actionable event entity. (See paragraph 89)
A computer program product. (See paragraph 98)
A non-transitory computer-readable storage medium. (See paragraphs 98-100)
An IoT device. (See paragraphs 43-44)
These additional elements are recited at a high-level of generality such that they act to merely “apply” the abstract idea using generic computing components and do not integrate the abstract idea into a practical application. (See MPEP 2106.05 (f))
The combination of these additional elements and/or results oriented steps are no more than mere instructions to apply the exception using generic computing components. (See MPEP 2106.05 (f)) Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to an abstract idea.
Step 2B (Does the claim recite additional elements that amount to Significantly More than the Judicial Exception?):
As noted above, the claims as a whole merely describes a method that generally “apply” the concepts discussed in prong 1 above. (See MPEP 2106.05 f (II)) In particular applicant has recited the computing components at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. As the court stated in TLI Communications v. LLC v. AV Automotive LLC, 823 F.3d 607, 613 (Fed. Cir. 2016) merely invoking generic computing components or machinery that perform their functions in their ordinary capacity to facilitate the abstract idea are mere instructions to implement the abstract idea within a computing environment and does not add significantly more to the abstract idea. Accordingly, these additional computer components do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea and as a result the claim is not patent eligible.
Dependent claims 2 and 9 further define the abstract idea as identified. Additionally the claim recites the generic business system (See paragraph 85), internet-of-things platform (See paragraph 85), and an IOT device (See paragraph 43-44) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 2 and 9 are considered to be patent ineligible.
Dependent claims 3 and 10 further defines the abstract idea as identified. Additionally the claim recites the generic actionable event entity (See paragraph 89) and aggregator (See paragraph 87) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 3 and 10 are considered to be patent ineligible.
Dependent claims 4-5 and 7, further define the abstract idea as identified. Additionally the claim recites the generic program code (See paragraphs 81-82) and the generic apparatus (See paragraph 75) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 4-5 and 7 are considered to be patent ineligible.
Dependent claim 6, further defines the abstract idea as identified. Additionally the claim recites the generic program code (See paragraphs 81-82), the generic apparatus (See paragraph 75) and database (See paragraph 84) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 6 is considered to be patent ineligible.
Dependent claims 11-15 and 17-19 further defines the abstract idea as identified. Therefore claims 11-15 and 17-19 are considered to be patent ineligible.
Dependent claim 16 further defines the abstract idea as identified. Additionally the claim recites a generic database (See paragraph 84) for merely implementing the abstract idea with generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 16 is considered to be patent ineligible.
In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and the collective functions merely provide conventional computer implementation. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-6, 8-13, 16, 14 and 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Bhatt et al. (US Patent No. 11,037,169)
Referring to claims 1, 8, and 20,
Bhatt, which is directed to automating support for an IOT device by a trusted agent, discloses
An apparatus comprising: one or more processors; and a memory coupled to the one or more processors and including a data structure and program code, the data structure including an aggregator having a plurality of workflow parameter fields and an actionable event entity, and the program code being configured so that, when executed by the one or more processors, the program code causes the apparatus to:
(Claim 8) A method, comprising: defining a data structure including an aggregator having a plurality of workflow parameter fields and an actionable event entity;
(Claim 20) A computer program product comprising: a non-transitory computer-readable storage medium; and program code stored on the non-transitory computer-readable storage medium that, when executed by one or more processors, causes the one or more processors to: define a data structure including an aggregator having a plurality of workflow parameter fields and an actionable event entity; (Bhatt column 3 lines 27-39 teaching a customer purchases an IoT appliance or a product from a manufacturing warehouse. In an exemplary embodiment, the following information is gathered: (a) complete product information; (b) expiration date of warranty; (c) validity and limits of warranty at the time of purchase; (d) warranty extension or supplemental insurance coverage if applicable; (e) customer contact details; (f) unique item identifier via a machine readable code (e.g., one dimensional barcode, two-dimensional barcode such as quick response (QR) code, etc.) All of the related warranty information can be accessed from a stored through an application programming interface (API) of a smart IoT device. (Bhatt column 3 line 47 to column 4 line 7 teaching in one particular example of vehicle parts, a manufacturer warehouse can track and monitor an inventory of required parts as part of a warranty management engine and as part of a service scheduling engine. For example, a manufacturer's system can determine servicing timelines for a purchased product such as an IoT device and automatically schedule servicing appointments at a customer's convenience. Alternatively, this information is forwarded to the mobile wallet during purchase to enable the mobile wallet to manage such future requirements. Either the manufacturer or the user mobile wallet can participate in managing any applicable warranties and inventory of the product purchased. The system is capable of applying extended warranty to individual customers based on their purchase history. The manufacturer can aggregate information received from IoT devices and push notifications to the user via a client warranty management engine executed by a user device having an enhanced mobile wallet. Alternatively, the client warranty management engine on the user device can detect the need for replacement or service of an IoT device and pull the required inventory or scheduling support from the manufacturer. Thereby, the manufacturer or other entity in the supply chain can manage or facilitate an improved lifecycle support process for subassemblies and assemblies of IoT devices. Bhatt column 4 lines 27-46 disclosing the following terms are used throughout the disclosure, the definitions of which are provided herein to assist in understanding one or more aspects of the disclosure. As used herein, the term “infer” or “inference” generally refer to the process of reasoning about or inferring states of a system, a component, an environment, a user from one or more observations captured via events or data, etc. Inference may be employed to identify a context or an action or may be employed to generate a probability distribution over states, for example. An inference may be probabilistic. For example, computation of a probability distribution over states of interest based on a consideration of data or events. Inference may also refer to techniques employed for composing higher-level events from a set of events or data. Such inference may result in the construction of new events or new actions from a set of observed events or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Bhatt column 4 line 58 to column 5 line 3 disclosing A network interface 106 accesses support information via a network associated with the unique identifier of the IoT device. A secure storage device 108 that is used by the mobile wallet 102 stores the unique identifier and support information. The storage can be local, physical storage or virtual interface to remote storage. A support operation engine 110 executes a support operation for the IoT device based on the unique identifier and support information in the secure storage device 108 accessed by the mobile wallet 102. For example, the support operation engine 110 can act as a warranty management engine or a repair and service scheduling engine. Bhatt column 5 lines 10-28 disclosing in one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. In one or more embodiments, the network interface 106 receives an alert from one of: (i) a manufacturer of the IoT device that receives diagnostic information originating on the IoT device; (ii) a system connected to the IoT device; and (iii) the IoT device. The support operation engine 110 generates a user alert on a user interface device of a user device to take a corrective action for to the IoT device. Bhatt column 10 lines 4-39 disclosing
FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302. Device data 322 gleaned by the warranty management engine 308 can be shared with a manufacturer system 324 for generating reliability data 326 that be used to shape recommended service intervals, size of required inventory, etc., sent as a product service message 328 by the service, replacement and scheduling module 306. FIG. 4 illustrates a system 400 for product registration with a mobile wallet based on an IoT complaint system. The sensors and monitors in all the IoT devices or products 402 provide a tremendous source of data to a manufacturer 404. A competitive advantage can be gained as to using that data to improve service delivery with predictive and remote activities. The capitalizing on the data by sharing the data with engineering and other parts of the organization can help with both product and service improvements. The incentive to an end user to allow sharing of the IoT device data is registering a warranty. To this end, at POS, MAC address as a serial number 406 is shared with the manufacturer 404 and a mobile wallet IoT management engine 408 to create a manufacturer warranty for an IoT device 410. Bhatt column 11 lines 41-49 disclosing FIG. 6 illustrates a system 600 including a computing device 612 configured to implement one or more embodiments provided herein. In one configuration, computing device 612 includes at least one processing unit 616 and memory 618. Depending on the exact configuration and type of computing device, memory 618 may be volatile, such as RAM, non-volatile, such as ROM, flash memory, etc., or a combination of the two. This configuration is illustrated in FIG. 6 by dashed line 614. Bhatt column 11 lines 54-62 disclosing such additional storage is illustrated in FIG. 6 by storage 620. In one or more embodiments, computer readable instructions to implement one or more embodiments provided herein are in storage 620. Storage 620 may store other computer readable instructions to implement an operating system, an application program, etc. Computer readable instructions may be loaded in memory 618 for execution by processing unit 616, for example.) The Examiner is interpreting that the system of Bhatt provides for data storage that includes the aggregation of information from different IOT devices and different sensors and therefore discloses a data structure including an aggregator and the associated warranty information that is stored as well that is used as the logic for determining whether a condition is triggered corresponds to the actionable event entity.)
receive an alarm based on data from an IoT device; (Bhatt column 5 lines 22-28 disclosing in one or more embodiments, the network interface 106 receives an alert from one of: (i) a manufacturer of the IoT device that receives diagnostic information originating on the IoT device; (ii) a system connected to the IoT device; and (iii) the IoT device. Certain functionalities of IoT device support operations can be performed by software applications resident in memory 618, such as mobile wallet 102, device interface 104, network interface 106, secure storage 108, support operation engine 110, wireless transceiver 112, and code scanner 114.)
parse the alarm into one or more parameters; (Bhatt column 10 lines 11-25 disclosing the warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302. Device data 322 gleaned by the warranty management engine 308 can be shared with a manufacturer system 324 for generating reliability data 326 that be used to shape recommended service intervals, size of required inventory, etc., sent as a product service message 328 by the service, replacement and scheduling module 306.)
update a value of each workflow parameter field of the aggregator that corresponds to one of the one or more parameters; (Bhatt column 3 line 47 to column 4 line 7 teaching in one particular example of vehicle parts, a manufacturer warehouse can track and monitor an inventory of required parts as part of a warranty management engine and as part of a service scheduling engine. For example, a manufacturer's system can determine servicing timelines for a purchased product such as an IoT device and automatically schedule servicing appointments at a customer's convenience. Alternatively, this information is forwarded to the mobile wallet during purchase to enable the mobile wallet to manage such future requirements. Either the manufacturer or the user mobile wallet can participate in managing any applicable warranties and inventory of the product purchased. The system is capable of applying extended warranty to individual customers based on their purchase history. The manufacturer can aggregate information received from IoT devices and push notifications to the user via a client warranty management engine executed by a user device having an enhanced mobile wallet. Alternatively, the client warranty management engine on the user device can detect the need for replacement or service of an IoT device and pull the required inventory or scheduling support from the manufacturer. Thereby, the manufacturer or other entity in the supply chain can manage or facilitate an improved lifecycle support process for subassemblies and assemblies of IoT devices. Bhatt column 10 lines 4-25 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302. Device data 322 gleaned by the warranty management engine 308 can be shared with a manufacturer system 324 for generating reliability data 326 that be used to shape recommended service intervals, size of required inventory, etc., sent as a product service message 328 by the service, replacement and scheduling module 306. The Examiner is interpreting that Bhatt discloses updating aggregated information based on received information from the IOT devices for subsequent use in determining whether a condition is triggered.)
determine if the alarm is actionable based on the values in the workflow parameter fields of the aggregator; (Bhatt column 3 lines 62 to column 4 line 7 disclosing the manufacturer can aggregate information received from IoT devices and push notifications to the user via a client warranty management engine executed by a user device having an enhanced mobile wallet. Alternatively, the client warranty management engine on the user device can detect the need for replacement or service of an IoT device and pull the required inventory or scheduling support from the manufacturer. Thereby, the manufacturer or other entity in the supply chain can manage or facilitate an improved lifecycle support process for subassemblies and assemblies of IoT devices. High availability of systems that depend on such IoT devices realized through such support can provide a good customer experience. In one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. Bhatt column 5 lines 10-20 disclosing the restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. The Examiner is interpreting that Bhatt discloses determining whether to provide a notification to a user based on the updated aggregated information received from the IOT devices.)
and in response to the alarm being actionable, using the actionable event entity to generate an actionable event that defines a response to the alarm. (Bhatt column 3 lines 62 to column 4 line 7 disclosing the manufacturer can aggregate information received from IoT devices and push notifications to the user via a client warranty management engine executed by a user device having an enhanced mobile wallet. Alternatively, the client warranty management engine on the user device can detect the need for replacement or service of an IoT device and pull the required inventory or scheduling support from the manufacturer. Thereby, the manufacturer or other entity in the supply chain can manage or facilitate an improved lifecycle support process for subassemblies and assemblies of IoT devices. High availability of systems that depend on such IoT devices realized through such support can provide a good customer experience. In one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. Bhatt column 5 lines 10-20 disclosing the restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102.) (Bhatt column 5 lines 11-21 disclosing in one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
Referring to claims 2 and 9,
Bhatt further discloses wherein the alarm is received from one or more of a business system, internet-of-things platform, and an IoT device. (Bhatt column 5 lines 22-28 disclosing in one or more embodiments, the network interface 106 receives an alert from one of: (i) a manufacturer of the IoT device that receives diagnostic information originating on the IoT device; (ii) a system connected to the IoT device; and (iii) the IoT device. Certain functionalities of IoT device support operations can be performed by software applications resident in memory 618, such as mobile wallet 102, device interface 104, network interface 106, secure storage 108, support operation engine 110, wireless transceiver 112, and code scanner 114.)
Referring to claims 3 and 10,
Bhatt further discloses wherein the actionable event entity determines which parameter fields in the aggregator contribute to generation of the actionable event. (Bhatt column 3 line 47 to column 4 line 7 teaching in one particular example of vehicle parts, a manufacturer warehouse can track and monitor an inventory of required parts as part of a warranty management engine and as part of a service scheduling engine. For example, a manufacturer's system can determine servicing timelines for a purchased product such as an IoT device and automatically schedule servicing appointments at a customer's convenience. Alternatively, this information is forwarded to the mobile wallet during purchase to enable the mobile wallet to manage such future requirements. Either the manufacturer or the user mobile wallet can participate in managing any applicable warranties and inventory of the product purchased. The system is capable of applying extended warranty to individual customers based on their purchase history. The manufacturer can aggregate information received from IoT devices and push notifications to the user via a client warranty management engine executed by a user device having an enhanced mobile wallet. Alternatively, the client warranty management engine on the user device can detect the need for replacement or service of an IoT device and pull the required inventory or scheduling support from the manufacturer. Thereby, the manufacturer or other entity in the supply chain can manage or facilitate an improved lifecycle support process for subassemblies and assemblies of IoT devices. Bhatt column 10 lines 4-25 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302. Device data 322 gleaned by the warranty management engine 308 can be shared with a manufacturer system 324 for generating reliability data 326 that be used to shape recommended service intervals, size of required inventory, etc., sent as a product service message 328 by the service, replacement and scheduling module 306. The Examiner interprets Bhatt discloses the rules provided by a warranty agreement control what parameters are used in determining whether to provide a notification to a user or in making a decision.
Referring to claims 4 and 11,
Bhatt further discloses wherein the program code further causes the apparatus to: determine if a first entitlement is triggered by the actionable event; (Bhatt column 5 lines 11-21 in one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
in response to the first entitlement being triggered, implement a first entitlement process; (Bhatt column 5 lines 11-21 In one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
and in response to the first entitlement not being triggered, determine if a second entitlement is triggered by the actionable event. (Bhatt column 5 lines 11-21 In one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
Referring to claims 5 and 12,
Bhatt further discloses wherein the first entitlement is a vendor warranty coverage, the second entitlement is a contract coverage, (Bhatt column 5 lines 11-21 disclosing in one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
and the program code causes the apparatus to determine if the second entitlement is triggered by the actionable event by: in response to the first entitlement not being triggered by the actionable event, determine if a contract is associated with the actionable event; (Bhatt column 5 lines 11-21 In one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102.)
and if the contract is associated with the actionable event, determining if the contract coverage applies to the actionable event. (Bhatt column 5 lines 11-21 In one or more embodiments, the support operation engine 110 determines occurrence of a trigger event that indicates applicability of a restitution obligation by the guarantor of the IoT device. The restitution obligation is according to terms of the selected one of: (i) the warranty agreement; and (ii) the insurance agreement. In response thereto, the support operation engine 110 requests, via the network interface 106, restitution by communicating to the guarantor one or more of: (a) user information; (b) the unique identifier, and (c) the support information in secure storage via the mobile wallet 102. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
Referring to claims 6 and 16,
Bhatt further discloses wherein the alarm identifies an asset, and the program code causes the apparatus to determine if the alarm is actionable by: determining an identity of at least one of the asset, a component of the asset, and a customer associated with the asset; (Bhatt column 9 lines 45-55 disclosing the mobile wallet client application 208 is a trusted agent to the user 208 and the other entities described above. This trust can be extended to entities that provide support for the purchased IoT device 229, such as a manufacturer system 260 that has an original equipment manufacturer (OEM) warranty engine 262 and a warranty database 264. The trust can be extended also to an insurer system 266 having an insurance policy management engine 268 that provides supplemental insurance to the warranty or an extended warranty policy to succeed an expired manufacturer warranty. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
querying a database for entitlements associated with the asset, the component, or the customer; (Bhatt column 9 lines 45-55 disclosing the mobile wallet client application 208 is a trusted agent to the user 208 and the other entities described above. This trust can be extended to entities that provide support for the purchased IoT device 229, such as a manufacturer system 260 that has an original equipment manufacturer (OEM) warranty engine 262 and a warranty database 264. The trust can be extended also to an insurer system 266 having an insurance policy management engine 268 that provides supplemental insurance to the warranty or an extended warranty policy to succeed an expired manufacturer warranty. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
and only determining the alarm is actionable if the database query returns at least one entitlement. (Bhatt column 9 lines 45-55 disclosing the mobile wallet client application 208 is a trusted agent to the user 208 and the other entities described above. This trust can be extended to entities that provide support for the purchased IoT device 229, such as a manufacturer system 260 that has an original equipment manufacturer (OEM) warranty engine 262 and a warranty database 264. The trust can be extended also to an insurer system 266 having an insurance policy management engine 268 that provides supplemental insurance to the warranty or an extended warranty policy to succeed an expired manufacturer warranty. Bhatt column 10 lines 4-19 disclosing FIG. 3 illustrates that main components of a warranty and service management system 300 can comprise a user device 302, warranty module 304, service-replacement-scheduling module 306, which gather all customer product information. A warranty management engine 308 can communicate with a manufacturer's warranty coverage database 310 and a third party's system 312 to get the related credit card and insurance information. The warranty management engine 308 can collect device issue data 314 that is received from a warranty module 304 on the user device 302 or directly from an IoT device itself or an assembly that includes an IoT device. The warranty management engine 308 can return a decision or outcome message 316 of a warranty coverage decision to the warranty module 304. For benefit of the user, the warranty management engine 308 can return a device notification 318 to a user interface 320 of the user device 302.)
Referring to claim 13,
Bhatt further discloses wherein the actionable event identifies a customer, and determining if the contract coverage applies to the actionable event comprises: determining