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 .
Status of the Claims
Claims 1-19 are presented for examination. Applicant filed a response to a non-final Office action on 02/19/2026 arguing against the previous § 101 and § 103 rejections of claims 1-19. Examiner has carefully considered Applicant’s arguments, but finds them not persuasive. Therefore, Examiner has maintained the previous § 101 and § 103 rejections of claims 1-19 in the instant Office action. Since Examiner has maintained the previous § 101 and § 103 rejections, the instant rejection of claims 1-19 is FINAL rejection of claims.
Examiner’s Remarks
Patent Eligibility under § 101:
Applicant argues in pages 8-10 of Applicant’s Remarks:
The specification at paragraph [0029] explains that unlike prior art centralized platforms prone to lack of transparency and data manipulation, Applicant's recited method uses blockchain's immutable recording to ensure integrity of quality-of-service data, enabling reliable, objective selection of service offers based on verified historical performance.
This is analogous to Example 42 provided by the USPTO, where claims were found eligible because additional elements "recite a specific improvement over prior art systems" by providing real- time standardized information sharing.
Similarly, the present claims provide a specific technological improvement: using blockchain's cryptographic immutability to solve the technical problem of unreliable service provider reputation data in decentralized marketplaces.
. . .
The additional elements of Claim 1 improve upon existing blockchain-based service matching methods by providing a specific technical improvement: reliable QoS score-based selection and sorting of service offers versus the suboptimal first-bidder assignment algorithms used in conventional blockchain-based service matching methods.
. . .
In Example 21 provided by the USPTO, Claim 2 was found eligible because "when looking at the additional limitations as an ordered combination, the invention...addresses the Internet-centric challenge" with "meaningful limitations that add more than generally linking the use of the abstract idea to the Internet".
Similarly, the present claims address the blockchain-centric challenge of decentralized service matching with verifiable reputation through the specific ordered combination of: blockchain-based immutable storage, smart contract automation, and cryptographically-secured historical performance data for objective scoring.
Examiner respectfully disagrees. First, Example 42 is not analogous with instant claims 1-19. Claim 1 of Example 42 is deemed patent eligible under § 101 because “the additional elements recite a specific improvement over prior art systems by allowing remote users to share information in real time in a standardized format regardless of the format in which the information was input by the user.” Thus, there is no similarity between claim 1 of Example 42 and instant claims 1-19 because there is no reformatting data anywhere in instant claims 1-19. Second, and as before, Applicant’s claims 1-19 recite no technological improvement or a solution to a technological problem. The instant claims merely recite a contract between service request and service offer. That the contract is a smart contract offers no technological improvement because the claims merely recite using the technology of smart contracts instead of improving the technology. Creating a smart contract for services belongs to “Certain Methods of Organizing Human Activity (i.e., commercial or legal interactions).” Instant claims reciting electronic interactions does not negate claims belonging to “Certain Methods of Organizing Human Activity (i.e., commercial or legal interactions)” because electronic activity would only create a problem with the group under “Mental Processes.” As such, instant claims 1-19 are not patent eligible under § 101.
Prior Art under § 103:
Applicant argues in page 12 of the Applicant’s Remarks:
1. Crossan does not disclose that "the sent candidate service offers are sorted according to a quality of service score" as recited in Claim 1 (emphasis added).
2. Crossan does not disclose that "the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain" as recited in Claim 1 (emphasis added).
Examiner respectfully disagrees. Crossan teaches specifically (emphasis by Examiner):
[0047] At 235, the received responses and offers are ranked in relation to each other based on at least one ranking criteria. The at least one ranking criteria may include one or more of the following: the quality of the match of the offer to the request, the previous history or reputation of the merchant or service provider submitting the offer or response, a successful history or previous interactions between the requestor and the merchant or service provider (or other users associated with the requestor), and the location of the merchant or service provider, as well as any other suitable signal or criteria. In some instances, the ranking and analysis can provide each response with a corresponding quality score to be used when comparing two or more responses or offers. Alternatively, a predicted click-through probability can be generated for each response to determine which of the responses or offers are most likely to be accepted or reviewed by the requesting user. In some instances, a bid value or amount submitted by the responding merchant or service provider may be considered when ranking offers or responses. The bid value or amount can represent a value associated with a particular action or event, such as a bid for sending a submitted offer to the requesting user or a bid for initiating an interaction between the merchant or service provider and the requesting user. The bid value may be combined with the quality score of a particular response or offer to generate a combined score or relative rating of a particular response.
[0055] At 279, a score representing the quality of each response or offer is calculated based, at least in part, on an analysis of the offer or response and information retrieved from the profile associated with the information source, merchant, or service provider from where the response or offer is received. For example, a key word analysis of the response or offer in light of the original request may be performed to determine whether the response or offer is responsive to the original request, with that determination being combined with one or more metrics associated with or stored in the profile corresponding with the source of that response or offer. In alternative implementations, different combinations may be used to perform the analysis. Additionally, only the calculated quality score of the responses or offers may be considered in some instances. Further, a bid value associated with each response is identified at 282. The various bid values may be associated with the same events (i.e., for providing the response to the requesting user), or the bid values may be associated with different events (i.e., bid 1 is associated with providing the response to the requesting user, while bid 2 is associated with the user's acceptance of the offer or response provided). At 285, a ranking score of each of the received responses is generated based on a combination of the calculated quality of response or offer and the bid value associated with those offers. In some instances, different weights may be applied to the quality score and the bid value according to the settings and parameters of the specific system. Once the ranking scores for each of the responses or offers are generated, the set of responses or offers can be sorted by their relative ranking scores at 288 to generate a sorted, ranked set of responses or offers. In some instances, the relative ranking scores may be further sorted or filtered based on additional criteria or determinations. At 291, the sorted set of responses may be limited or filtered based on the number of responses or offers to be returned to the requesting user. For example, if only ten responses are to be returned, only the top ten responses in the sorted set will be retained or included in the set of responses to be provided to the user. In some instances, the other responses may be stored in case none of the top ten responses is selected by the user.
Crossan, thus, teaches: the quality score is based on the quality of service criteria; each received offer has a ranking score based on the weighted quality score; received offers are sorted by their relative ranking scores generating a sorted, ranked set of responses or offers; and the sorted offers may be limited or filtered based on the number of offers to be returned to the requesting user. Therefore, Crossan teaches:
the sent candidate service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and
the history of services, associated with the candidate service offer, and the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain.
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-19 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 1-15 and 19 is a series of steps, which is method (i.e., a process) and, thus, one of the statutory categories of invention. Further, the claimed invention of claims 16-18 is a system, which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 1-19 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 1-19, however, recite an abstract idea of service provision in a blockchain. The creation of service provision in a blockchain, as recited in the independent claims 1, 16, 18, and 19, belongs to certain methods of organizing human activity (i.e., commercial or legal interactions) that are found by the courts to be abstract ideas. The limitation in independent claim 1, which sets forth or describe the recited abstract idea, is found in the following step:
“identifying at least one service offer that meets the at least one service selection criterion, referred to as a candidate service offer, from among service offers already recorded in the blockchain upon receiving at least one service request comprising at least one service selection criterion and at least one quality of service rule” (claims 1 and 19).
Prong 2: In addition to abstract step recited above in Prong 1, independent claims 1, 16, 18, and 19, recite additional elements:
“a smart contract of the blockchain, the smart contract being executed by at least a node belonging to the blockchain, the node comprising at least one hardware processor and at least one computer-readable memory coupled to the at least one hardware processor and in which are saved program code instructions executable by the at least one hardware processor to implement the method of computer-implemented service provision, the smart contract implementing a range of functions necessary to connect service providers and principals” (claims 1 and 19);
“at least one client device” (claims 1 and 19);
“a communication network” (claims 1 and 19);
“a hardware processor” (claims 16 and 18);
“a memory storing instructions” (claims 16 and 18);
“a transmission module” (claims 16 and 18); and
“a reception module” (claims 16 and 18).
These additional elements are recited at a high level of generality such that they amount to no more than mere instructions to apply the exception using a generic computer component. Also, the following additional limitations recite insignificant extra solution activity (for example, data gathering):
“sending at least one of candidate service offers, the at least one sent candidate service offer being selected in a transparent and objective manner on the basis of the at least one quality of service rule and of a history of services, the history of services being associated with the candidate service offers and unforgeably recorded in the blockchain, wherein the sent candidate service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, [and] wherein the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain” (claim 1);
“transmit at least one service request, the at least one service request comprising at least one service selection criterion and at least one quality of service rule” (claim 16);
“receive at least one candidate service offer that meets the at least one service selection criterion and is selected in a transparent and objective manner from among service offers already recorded in a blockchain of the communication network on the basis of the at least one quality of service rule and of a history of services, the history of services being associated with the candidate service offers and unforgeably recorded in the blockchain, wherein the received candidate service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, wherein the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain” (claim 16);
“transmit a service offer comprising at least one service selection criterion and intended to be recorded in a blockchain of the communication network” (claim 18);
“receive a contract binding a service request recorded in the blockchain and the transmitted service offer selected in a transparent and objective manner from among service offers already recorded in the blockchain on the basis of at least one quality of service rule contained in the service request and of a history of services, the history of services being associated with the provider device and unforgeably recorded in the blockchain and the at least one quality of service rule being a weighted combination of service selection criteria recorded in the blockchain” (claim 18); and
“sending at least one of candidate service offers, the at least one sent candidate service offer being selected in a transparent and objective manner on the basis of the at least one quality of service rule and of a history of services, the history of services being associated with the candidate service offers and unforgeably recorded in the blockchain, wherein the at least one service request also comprises a validity period of the at least one service request and identifying candidate service offers is iterated until end of the validity period as long as no candidate service offer has been identified” (claim 19).
These additional limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional limitations of independent claims 1, 16, and 18, here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations). Further, the combination of these additional elements/limitations is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements /limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Conclusion of Step 2A Analysis: Therefore, independent claims 1, 16, 18, and 19, are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 1, 16, 18, and 19, are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. The Applicant’s Specification describes these additional elements in following terms:
[0007] Blockchain infrastructures have recently been enriched with "smart contracts", that can be defined as autonomous programs that automatically perform the terms and conditions of a contract, without requiring any human intervention. In other words, a smart contract is a compiled computer program that carries a set of features allowing it to perform automatically and autonomously at least some of the specific clauses of the contract it carries. The emergence of these smart contracts opens up new applications for blockchains, particularly in the exchange of goods and services.
[0060] The client device of a principal 102 can comprise a transmission/ reception RX/TX module 1020, configured to transmit service requests to the platform 100 as well as an assessment of a service provided, and to receive candidate service offers, selected by the platform 100. Such a client device can in particular comprise one or more processors, configured to execute program code instructions for transmitting and receiving such data, in particular in accordance with the HTML (HyperText Markup Language) and JS (JavaScript) programming languages.
This is a description of general-purpose computer performing usual functions. Further, the additional limitations of “transmitting,” “sending,” and “receiving” information amount to no more than mere instructions to apply the exception using generic computer components. For the same reason these additional limitations are not sufficient to provide an inventive concept. The additional limitations of “transmitting,” “sending,” and “receiving” information were considered insignificant extra-solution activity in Step 2A – Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), the additional limitations of independent claims 1, 16, 18, and 19, "transmit," "send," and "receive" information over a network in a merely generic manner. The courts have recognized "transmitting," "sending," and "receiving" information functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional limitations of independent claims 1, 16, 18, and 19, are well-understood, routine, and conventional. Further, taken as combination, the additional elements/limitations add nothing more than what is present when the elements are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 1, 16, 18, and 19, are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 2-15 depend on independent claim 1; and dependent claim 17 depends on independent claim 16. The elements in dependent claims 2-15 and 17, which set forth or describe the abstract idea, are:
"the smart contract implements a reception of a plurality of service requests" (claim 2: further narrowing the recited abstract idea);
"the smart contract implements the reception of the plurality of service requests transmitted by a plurality of client devices of the communication network" (claim 3: further narrowing the recited abstract idea);
"the at least one client device transmitting the at least one service request and/or at least one device providing at least one of the service offers recorded in the blockchain interact(s) with the smart contract via at least one application programming interface (API) request using at least one function implemented by the smart contract and belonging to a following group: a function for recording the at least one service request and/or at least one service offer in the blockchain; a function for filtering recorded service offers according to the at least one service selection criterion comprised in the at least one service request; a function for sorting service offers that meet the at least one selection criterion comprised in the at least one service request; a function for establishing a contract between a device providing at least one of the service offers and a client device transmitting at least one of the service requests; and a function for recording in the blockchain a quality of service corresponding to a provided service" (claim 4: further narrowing the recited abstract idea);
"the functions of the smart contract implement consensus rules" (claim 5: further narrowing the recited abstract idea);
"the sent service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer" (claim 6: further narrowing the recited abstract idea);
"the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain" (claim 7: further narrowing the recited abstract idea);
"the at least one service request also comprises a validity period of the at least one service request" (claim 8: further narrowing the recited abstract idea);
"the identification of candidate service offers is iterated until the end of the validity period as long as no candidate service offer has been identified" (claim 9: further narrowing the recited abstract idea);
"the history of services is recorded in the blockchain in association with a set of values assigned to service selection criteria for the service" (claim 10: further narrowing the recited abstract idea);
"the quality of service score is calculated by utilizing the weighted or exponential moving average of values of the history of services based on the at least one quality of service rule" (claim 11: further narrowing the recited abstract idea);
"after provision of required service: receiving and recording, in the blockchain, values assigned to service selection criteria for provided service; and updating, in the blockchain, a status of the required service" (claim 12: further narrowing the recited abstract idea);
"receiving a service offer; and recording the service offer in the blockchain” (claim 13: where "receiving" is insignificant extra solution activity; and "recording" is further narrowing the recited abstract idea);
"the service provision method is implemented by a computer program comprising program code instructions stored in a non-transitory computer-readable storage medium" (claim 14: further narrowing the recited abstract idea);
"a node belonging to a blockchain network configured to execute the smart contract of the blockchain, wherein the node comprises: at least one processor; and at least one computer-readable memory coupled to the at least one processor storing program code instructions executable by the at least one processor to implement the service provision method" (claim 15: further narrowing the recited abstract idea); and
"the transmission module is configured to transmit values assigned to service selection criteria for a provided service intended to be recorded in the blockchain” (claim 17: insignificant extra solution activity).
Conclusion of Dependent Claims Analysis: Dependent claims 2-15 and 17 do not correct deficiencies of independent claims 1 and 16 and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 1-19 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in § 102 of this title, 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-19 are rejected under 35 U.S.C. § 103 as being unpatentable over Kadarmandalgi (US 2020/0372501 A1) in view of Crossan (US 2014/0365327 A1).
As to independent claim 1
Kadarmandalgi shows:
the smart contract being executed by at least a node belonging to the blockchain, the node comprising at least one hardware processor and at least one computer-readable memory coupled to the at least one hardware processor and in which are saved program code instructions executable by the at least one hardware processor to implement the method of computer-implemented service provision, the smart contract implementing a range of functions necessary to connect service providers and principals (Kadarmandalgi: page 1, ¶ 3);
upon receiving at least one service request, from at least one client device of the communication network, the service request comprising at least one service selection criterion and at least one quality of service rule, identifying at least one service offer that meets the at least one service selection criterion, referred to as candidate service offer, from among service offers already recorded in the blockchain (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶ 84); and
sending, to the at least one client device, at least one of candidate service offers, the at least one sent candidate service offer being selected in a transparent and objective manner on the basis of the at least one quality of service rule and of a history of services, the history of services being associated with the candidate service offers and unforgeably recorded in the blockchain (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶¶ 84-85).
Kadarmandalgi does not show:
the sent candidate service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, and the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain.
Crossan shows:
the sent candidate service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, and the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain (Crossan: page 8, ¶ 47; and pages 9-10, ¶ 55).
Motivation to combine Kadarmandalgi and Crossan:
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Kadarmandalgi by the sent candidate service offers being sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, and the at least one quality of service rule being a weighted combination of service selection criteria recorded in the blockchain of Crossan in order to provide top responses to the user (Crossan: page 10, ¶ 55).
As to claim 2, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the smart contract implements a reception of a plurality of service requests (Kadarmandalgi: page 4, ¶ 49; and page 8, ¶ 84).
As to claim 3, Kadarmandalgi in view of Crossan shows all the elements of claim 2. Kadarmandalgi also shows that the smart contract implements the reception of the plurality of service requests transmitted by a plurality of client devices of the communication network (Kadarmandalgi: page 7, ¶ 77; and page 8, ¶ 84).
As to claim 4, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the at least one client device transmitting the at least one service request and/or at least one device providing at least one of the service offers recorded in the blockchain interact(s) with the smart contract via at least one application programming interface (API) request using at least one function implemented by the smart contract (Kadarmandalgi: page 3, ¶ 40) and belonging to a following group: a function for recording the at least one service request and/or at least one service offer in the blockchain (Kadarmandalgi: page 4, ¶ 49); a function for filtering recorded service offers according to the at least one service selection criterion comprised in the at least one service request (Kadarmandalgi: page 8, ¶ 84); a function for sorting service offers that meet the at least one selection criterion comprised in the at least one service request (Kadarmandalgi: page 8, ¶ 84); a function for establishing a contract between a device providing at least one of the service offers and a client device transmitting at least one of the service requests (Kadarmandalgi: pages 8-9, ¶ 88); and a function for recording in the blockchain a quality of service corresponding to a provided service (Kadarmandalgi: page 8, ¶ 84).
As to claim 5, Kadarmandalgi in view of Crossan shows all the elements of claim 4. Kadarmandalgi also shows that the functions of the smart contract implement consensus rules (Kadarmandalgi: page 4, ¶ 49).
As to claim 6, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the sent service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer (Kadarmandalgi: page 8, ¶ 84).
As to claim 7, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain (Kadarmandalgi: page 8, ¶ 84).
As to claim 8, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the at least one service request also comprises a validity period of the at least one service request (Kadarmandalgi: page 3, ¶ 32).
As to claim 9, Kadarmandalgi in view of Crossan shows all the elements of claim 8. Kadarmandalgi also shows that the identification of candidate service offers is iterated until the end of the validity period as long as no candidate service offer has been identified (Kadarmandalgi: page 8, ¶ 85).
As to claim 10, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the history of services is recorded in the blockchain in association with a set of values assigned to service selection criteria for the service (Kadarmandalgi: page 8, ¶ 84).
As to claim 11, Kadarmandalgi in view of Crossan shows all the elements of claim 6. Kadarmandalgi also shows that the quality of service score is calculated by utilizing the weighted or exponential moving average of values of the history of services based on the at least one quality of service rule (Kadarmandalgi: pages 4-5, ¶ 53; and page 8, ¶ 84).
As to claim 12, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that after provision of required service: receiving and recording, in the blockchain, values assigned to service selection criteria for provided service and updating, in the blockchain, a status of the required service (Kadarmandalgi: pages 4-5, ¶ 53; and page 8, ¶ 84).
As to claim 13, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the method also comprises, implemented by the smart contract of the blockchain: receiving a service offer and recording the service offer in the blockchain (Kadarmandalgi: page 4, ¶ 49).
As to claim 14, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows that the service provision method is implemented by a computer program comprising program code instructions stored in a non-transitory computer-readable storage medium (Kadarmandalgi: pages 3-4, ¶ 45; and page 4, ¶ 46).
As to claim 15, Kadarmandalgi in view of Crossan shows all the elements of claim 1. Kadarmandalgi also shows a node belonging to a blockchain network configured to execute the smart contract of the blockchain, wherein the node comprises: at least one processor (Kadarmandalgi: pages 3-4, ¶ 45; and page 5, ¶ 54); and at least one computer-readable memory coupled to the at least one processor storing program code instructions executable by the at least one processor to implement the service provision method (Kadarmandalgi: pages 3-4, ¶ 45; and page 5, ¶ 54).
As to independent claim 16
Kadarmandalgi shows:
a transmission module configured to transmit at least one service request, the at least one service request comprising at least one service selection criterion and at least one quality of service rule (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶ 84); and
a reception module configured to receive at least one candidate service offer that meets the at least one service selection criterion and is selected in a transparent and objective manner from among service offers already recorded in a blockchain of the communication network on the basis of the at least one quality of service rule and of a history of services, the history of services being associated with the candidate service offers and unforgeably recorded in the blockchain (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶ 84).
Kadarmandalgi does not show:
the received candidate service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, wherein the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain.
Crossan shows:
the received candidate service offers are sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, wherein the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain (Crossan: page 8, ¶ 47; and pages 9-10, ¶ 55).
Motivation to combine Kadarmandalgi and Crossan:
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Kadarmandalgi by the received candidate service offers being sorted according to a quality of service score calculated for a candidate service offer, from the at least one quality of service rule, and the history of services, associated with the candidate service offer, and the at least one quality of service rule being a weighted combination of service selection criteria recorded in the blockchain of Crossan in order to provide top responses to the user (Crossan: page 10, ¶ 55).
As to claim 17, Kadarmandalgi in view of Crossan shows all the elements of claim 16. Kadarmandalgi also shows that the transmission module is configured to transmit values assigned to service selection criteria for a provided service intended to be recorded in the blockchain (Kadarmandalgi: page 7, ¶ 77; and page 8, ¶ 84).
As to independent claim 18
Kadarmandalgi shows:
a transmission module configured to transmit a service offer comprising at least one service selection criterion and intended to be recorded in a blockchain of the communication network (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶ 84); and
a reception module configured to receive a contract binding a service request recorded in the blockchain and the transmitted service offer selected in a transparent and objective manner from among service offers already recorded in the blockchain on the basis of at least one quality of service rule contained in the service request and of a history of services, the history of services being associated with the provider device and unforgeably recorded in the blockchain (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶ 84).
Kadarmandalgi does not show:
the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain.
Crossan shows:
the at least one quality of service rule is a weighted combination of service selection criteria recorded in the blockchain (Crossan: page 8, ¶ 47; and pages 9-10, ¶ 55).
Motivation to combine Kadarmandalgi and Crossan:
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Kadarmandalgi by the at least one quality of service rule being a weighted combination of service selection criteria recorded in the blockchain of Crossan in order to provide top responses to the user (Crossan: page 10, ¶ 55).
As to independent claim 19
Kadarmandalgi shows:
the smart contract being executed by at least a node belonging to the blockchain, the node comprising at least one hardware processor and at least one computer-readable memory coupled to the at least one hardware processor and in which are saved program code instructions executable by the at least one hardware processor to implement the method of computer-implemented service provision, the smart contract implementing a range of functions necessary to connect service providers and principals (Kadarmandalgi: page 1, ¶ 3);
upon receiving at least one service request, from at least one client device of the communication network, the service request comprising at least one service selection criterion and at least one quality of service rule, identifying at least one service offer that meets the at least one service selection criterion, referred to as candidate service offer, from among service offers already recorded in the blockchain (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶ 84); and
sending, to the at least one client device, at least one of candidate service offers, the at least one sent candidate service offer being selected in a transparent and objective manner on the basis of the at least one quality of service rule and of a history of services, the history of services being associated with the candidate service offers and unforgeably recorded in the blockchain (Kadarmandalgi: page 4, ¶ 49 and ¶ 51; page 7, ¶ 77; and page 8, ¶¶ 84-85).
Kadarmandalgi does not show:
the at least one service request also comprises a validity period of the at least one service request and identifying candidate service offers is iterated until end of the validity period as long as no candidate service offer has been identified.
Crossan shows:
the at least one service request also comprises a validity period of the at least one service request and identifying candidate service offers is iterated until end of the validity period as long as no candidate service offer has been identified (Crossan: page 9, ¶ 52; and page 11, ¶ 66).
Motivation to combine Kadarmandalgi and Crossan:
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Kadarmandalgi by the at least one service request also comprising a validity period of the at least one service request and identifying candidate service offers being iterated until end of the validity period as long as no candidate service offer has been identified of Crossan in order to provide top responses to the user (Crossan: page 10, ¶ 55).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mertz (AU 2019283831 A1) discloses: “A computer system for recommending merchants to a candidate cardholder is provided. The computer system includes a memory device in communication with a processor. The processor is programmed to receive transaction information for a plurality of cardholders from a payment network. The transaction information includes data relating to purchases made by the cardholders at a plurality of merchants, the purchases satisfying a first criteria. The processor receives candidate cardholder preference information for at least one of the merchants input by the candidate cardholder. The computer system determines a merchant rank for each merchant based on the received transaction information and the candidate cardholder preference information, and determines a neutral merchant rank for each merchant based on the received transaction information and neutral cardholder preferences of the plurality of cardholders. The computer system also determines a merchant score for each of the plurality of merchants by comparing the merchant rank to the neutral merchant rank.”
M. Chen, C. Tan, X. Zhu and X. Zhang, "A Blockchain-Based Authentication and Service Provision Scheme for Intemet of Things," 2020 IEEE Globecom Workshops (GC Wkshps, Taipei, Taiwan, 2020, pp. 1-6.
T. A. Alghamdi, I. Ali, N. Javaid and M. Shafiq, "Secure Service Provisioning Scheme for Lightweight IoT Devices With a Fair Payment System and an Incentive Mechanism Based on Blockchain," in IEEE Access, vol. 8, pp. 1048-1061, 2020.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday – Friday, 10 am – 6 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691