DETAILED ACTION
This Office action is in reply to application no. 18/982,202, filed 16 December 2024. Claims 1-17 are pending and are considered below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims lie within statutory categories of invention, as each is directed to a method (process), device (machine), or non-transitory computer readable medium (manufacture). The claim(s) recite(s) requesting a code, performing service code rendering in no particular manner, sending information to a user, performing payment processing, reading invoice information, and sending data to another entity.
As the whole point of this is to manage payment information, it recites a fundamental business practice and a commercial interaction; merchants have been managing payment information for decades, including before there was any such thing as a computer. Further, in the absence of computers, these are steps that can be performed mentally and/or by the use of paper records.
A merchant can create a service code by simply assigning a number to a particular customer request, can perform whatever service was requested, and can send and receive invoices and payments with identifiers on them. None of this presents any practical difficulty and none requires any technology beyond pen and paper.
This judicial exception is not integrated into a practical application because aside from the bare inclusion of a generic computer, discussed below, nothing is done beyond what was set forth above, which does not go beyond generally linking the abstract idea to the technological environment of networked computers. See MPEP § 2106.05(h).
As the claims only manipulate data pertaining to invoices, payments and the like, they do not improve the “functioning of a computer” or of “any other technology or technical field”. See MPEP § 2106.05(a). They do not apply the abstract idea “with, or by use of a particular machine”, MPEP § 2106.05(b), as the below-cited Guidance is clear that a generic computer is not the particular machine envisioned.
They do not effect a “transformation or reduction of a particular article to a different state or thing”, MPEP § 2106.05(c). First, such data, being intangible, are not a particular article at all. Second, the claimed manipulation is neither transformative nor reductive; as the courts have pointed out, in the end, data are still data.
They do not apply the abstract idea “in some other meaningful way beyond generally linking [it] to a particular technological environment”, MPEP § 2106.05(e), as the lack of technical and algorithmic detail in the claims is so as not to go beyond such a general linkage.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional claim limitations, considered individually and as an ordered combination, are insufficient to elevate an otherwise-ineligible claim to patent eligibility.
Claim 16, which has the most, includes a processor, memory storing instructions, and implicitly, access to some kind of network. These elements are recited at a high degree of generality and the specification is explicit, ¶ 149, that nothing more than a “general-purpose computer” is required.
It only performs generic computer functions of nondescriptly manipulating data and sharing data with persons and/or other devices. Generic computers performing generic computer functions, without an inventive concept, do not amount to significantly more than the abstract idea.
The type of information being manipulated does not impose meaningful limitations or render the idea less abstract. The claim elements when considered in ordered combination – a generic computer performing a chronological sequence of abstract steps – do nothing more than when they are analyzed individually.
The other independent claims are simply different embodiments but are likewise directed to a generic computer performing, essentially, the same process. The dependent claims further do not amount to significantly more than the abstract idea: claims 2 and 3 are simply further descriptive of the type of information being manipulated. Claims 4-9, 12, 14 and 15 simply recite further, abstract manipulation of data. Claims 10 and 13 simply specify storing and/or outputting data; claim 11 simply recites additional input.
The claims are not patent eligible. The Examiner has thoroughly reviewed the originally-filed application, including the specification and drawing sheets, and finds nothing likely sufficient to overcome this rejection.
For further guidance please see MPEP § 2106.03 – 2106.07(c) (formerly referred to as the “2019 Revised Patent Subject Matter Eligibility Guidance”, 84 Fed. Reg. 50, 55 (7 January 2019)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 7-12 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Maibach et al. (U.S. Patent No. 11,501,281, filed 25 June 2021) in view of Jones et al. (U.S. Publication No. 2022/0198433).
In-line citations are to Maibach.
With regard to Claim 1:
Maibach teaches: A service processing method, comprising:
based on an access instruction of a user for a target service, [Col. 28, lines 17-18; a user makes a purchase from a merchant using a device, and the system tracks data corresponding to the purchase such as “purchase amount” and date and time of purchase; Col. 27, line 34; the merchant may offer “goods or services”] generating a service code creation request comprising service access information… and sending the service code creation request to a service platform; [Col. 29, lines 47-48, the system may create a “one-time code” to send to a “server computing device” in response to a card swipe or other means for accessing a payment card]
performing service code rendering based on service code information returned after the service platform performs service code creation, and sending a rendered service code corresponding to the access instruction to the user; [id.; the one-time code is matched with a copy maintained elsewhere; Col. 30, line 3; the computers “exchange payment information and transaction data”, any of which read on an access instruction or a service code]
performing payment processing based on a payment request submitted after a merchant terminal scans the service code… after payment succeeds [Col. 24, lines 30-31; the POS device “scans a QR code” and then, line 44-45, sends “an indication of the scan to the payment service”, which reads on a step in the performance of payment processing; abstract; the payment may have been “processed using the wireless payment reader”] and
sending the invoice application information to the merchant terminal to perform invoice issuance. [Col. 38, lines 43-45; “payment data can be transmitted to the server computing device(s) 1002 and/or the server computing device(s) 1010 for processing”; the payment data reads on invoice application information; the phrase “to perform invoice issuance” is merely a statement of manner of use which is considered but given no patentable weight]
Maibach does not explicitly teach that a code comprises a user identity identifier, or reading invoice application information associated with a service code identifier comprised in the payment request, but it is known in the art. Jones teaches a reconciliation processing system [title] in which a “unique customer identifier” is associated with a user. [0044] The user identifier may be a numeric code such as “3108”. [0049] The system may “parse” elements of “formatted invoice data” to obtain payment information, [0045] and may execute a “real-time payment” once approved by a user. [0051] It may send confirmation data based on an approval of a payment. [0028] It may “validate” any portion of a message and, in response, generate, send and receive confirmation of a payment. [0051] Jones and Maibach are analogous art as each is directed to electronic means for managing payments.
It would have been obvious to one of ordinary skill in the art just prior to the filing of the claimed invention to combine the teaching of Jones with that of Maibach in order to improve security, as taught by Jones; [0108] further, it is simply a substitution of known parts for others with predictable results, simply storing Jones’ user code in place of, or in addition to, Maibach’s user data, and obtaining invoice data by the means of Jones rather than those of Maibach; the substitutions produce no new and unexpected result.
Many of the claims include a relative timing parameter, e.g. “X happens before Y”. In general this is an obvious variation; as two events can only happen in time, relative to each other, in three ways – X before Y, X and Y contemporaneously, or X after Y – it would be obvious to one of ordinary skill in the art to select any from such a short list with a reasonable expectation of success.
With regard to Claim 2:
The service processing method according to claim 1, wherein the service platform creates a service code record of the user based on the user identity identifier, and the service code record comprises the service code identifier; and
the service code corresponding to the access instruction is created based on at least one of the service code identifier, an access device identifier, an access address, or creation time. [Maibach as cited above in regard to claim 1; any collection of the data reads on a service code record and user information is stored with it; the service code identifier (indication of what was purchased) is also stored]
With regard to Claim 3:
The service processing method according to claim 1, wherein
the service code comprises a payment code of the user created by using the user as an access subject and a payment subject, and correspondingly, the target service comprises a first service used to access the payment code of the user; or
the service code comprises a payment code of an institution created by using the institution as a payment subject and the user as an access subject, and correspondingly, the target service comprises a second service used to access the payment code of the institution. [Maibach as cited above in regard to claim 1; the one-time code reads on the claimed payment code; the merchant reads on a payment subject and the customer on an access subject; the payment service reads on the claimed second service]
With regard to Claim 4:
The service processing method according to claim 1, before generating the service code creation request comprising the service access information and the user identity identifier and sending the service code creation request to the service platform, further comprising:
acquiring user information based on the user identity identifier, generating a service request comprising the user information, and sending the service request to the service platform; [Col. 21, lines 63-65; a user device scans a barcode or QR code; Col. 22, lines 17-19; it then sends data to the service provider] and
receiving the service code identifier returned after the service platform creates a service code record based on the service request, wherein
there is an association relationship between the service code identifier and a user identifier of the user, and the service code record comprises the user identity identifier. [Col. 22, lines 36-37; the system then generates data to send in order to connect to a payment device; at most this is simply a substitution of one known datum for another with predictable results compared to the data sent in claim 1]
With regard to Claim 7:
The service processing method according to claim 1, before generating the service code creation request comprising the service access information and the user identity identifier and sending the service code creation request to the service platform, further comprising:
generating a service request based on institution service information submitted by an authorized member of an institution to which the user belongs, and sending the service request to the service platform, wherein the institution service information comprises an identifier of the institution; [Col. 25, lines 8-9; it processes information based on a request; Col. 23, lines 25-26; it uses information about a “merchant associated with” the device; Col. 31, lines 53-54; the system keeps track of merchant accounts] and
sending a record creation result to the authorized member based on an institution code identifier returned by the service platform; [Jones, 0028 as cited above in regard to claim 1] or performing institution code rendering based on institution code information associated with a created institution code record and returned by the service platform, and sending a rendered institution code to the authorized member to send the institution code to an institution user of the institution.
As this claim does not include the step of submitting service information, that it was “submitted by an authorized member of an institution to which the user belongs” consists entirely of nonfunctional, descriptive language which is considered but given no patentable weight.
With regard to Claim 8:
The service processing method according to claim 1, wherein the service code creation comprises:
reading an access device identifier and an access address in the service access information, and reading the service code identifier associated with the user identity identifier; [Col. 26, lines 21-22; “first data identifying the payment reader”; Col. 36, line 47; a user’s “address” is obtained; Col. 29, lines 47-48 as cited above in regard to claim 1; the service code identifier is used] and
creating the service code based on the access device identifier, the access address, the service code identifier, and creation time. [id.; Col. 28, line 19; “time of purchase” is used; at most this step simply requires a substitution of known data for other known data with predictable results]
With regard to Claim 9:
The service processing method according to claim 1, wherein the service code creation comprises:
reading an institution identifier associated with the user identity identifier, and reading the service code identifier associated with the institution identifier; [Col. 25, lines 8-9; it processes information based on a request; Col. 23, lines 25-26; it uses information about a “merchant associated with” the device; Col. 31, lines 53-54; the system keeps track of merchant accounts] and
creating the service code based on the service code identifier, creation time, and at least one of an access device identifier or an access address in the service access information. [id.; Col. 28, line 19; “time of purchase” is used; at most this step simply requires a substitution of known data for other known data with predictable results]
With regard to Claim 10:
The service processing method according to claim 1, further comprising:
after payment succeeds, updating a service status of the service code to a paid state, [Col. 48, lines 27-29; “statuses” of orders are maintained including information about the “payment instruments” used to make purchases; some of the statuses are post-payment statuses such as “delivered”] and sending a payment success result to the merchant terminal. [Jones, 0028 as cited above in regard to claim 1]
With regard to Claim 11:
The service processing method according to claim 10, further comprising:
acquiring the service code identifier submitted by the merchant terminal, before the reading the invoice application information associated with the service code identifier comprised in the payment request. [Col. 29, lines 47-48 as cited above in claim 1; the server must receive the code before it can use it in any way]
With regard to Claim 12:
The service processing method according to claim 1, further comprising:
performing validity verification on the service code based on the service code identifier submitted after the merchant terminal scans the service code; [Jones, 0051 as cited above in regard to claim 1]
in response to verification success, sending a scenario service request comprising the service code identifier to the service platform; and querying, by the service platform, service scenario information in a service code record associated with the service code identifier, and returning the service scenario information; and
sending, to the merchant terminal, the service scenario information returned by the service platform. [id.]
With regard to Claim 15:
The service processing method according to claim 1, wherein the sending the invoice application information to the merchant terminal comprises:
determining a payment scenario corresponding to the payment request based on payment information comprised in the payment request; and
extracting scenario invoice application information corresponding to the payment scenario from the invoice application information, and sending the scenario invoice application information to the merchant terminal. [Jones, 0045 as cited above; it parses the elements of an invoice to obtain such items as a payment date and amount; it then sends that data to the server]
With regard to Claim 16:
Maibach teaches: A service processing device, comprising:
a processor; and
a memory storing instructions executable by the processor,
wherein the processor is configured [Col. 49, lines 17-20; “computer-executable instructions stored on one or more computer-readable storage media that, when executed by processor(s), perform the recited operations”] to:
based on an access instruction of a user for a target service, [Col. 28, lines 17-18; a user makes a purchase from a merchant using a device, and the system tracks data corresponding to the purchase such as “purchase amount” and date and time of purchase; Col. 27, line 34; the merchant may offer “goods or services”] generate a service code creation request comprising service access information… and send the service code creation request to a service platform; [Col. 29, lines 47-48, the system may create a “one-time code” to send to a “server computing device” in response to a card swipe or other means for accessing a payment card]
perform service code rendering based on service code information returned after the service platform performs service code creation, and send a rendered service code corresponding to the access instruction to the user; [id.; the one-time code is matched with a copy maintained elsewhere; Col. 30, line 3; the computers “exchange payment information and transaction data”, any of which read on an access instruction or a service code]
perform payment processing based on a payment request submitted after a merchant terminal scans the service code… after payment succeeds [Col. 24, lines 30-31; the POS device “scans a QR code” and then, line 44-45, sends “an indication of the scan to the payment service”, which reads on a step in the performance of payment processing; abstract; the payment may have been “processed using the wireless payment reader”] and
send the invoice application information to the merchant terminal to perform invoice issuance. [Col. 38, lines 43-45; “payment data can be transmitted to the server computing device(s) 1002 and/or the server computing device(s) 1010 for processing”; the payment data reads on invoice application information; the phrase “to perform invoice issuance” is merely a statement of manner of use which is considered but given no patentable weight]
Maibach does not explicitly teach that a code comprises a user identity identifier, or read invoice application information associated with a service code identifier comprised in the payment request, but it is known in the art. Jones teaches a reconciliation processing system [title] in which a “unique customer identifier” is associated with a user. [0044] The user identifier may be a numeric code such as “3108”. [0049] The system may “parse” elements of “formatted invoice data” to obtain payment information, [0045] and may execute a “real-time payment” once approved by a user. [0051] It may send confirmation data based on an approval of a payment. [0028] It may “validate” any portion of a message and, in response, generate, send and receive confirmation of a payment. [0051] Jones and Maibach are analogous art as each is directed to electronic means for managing payments.
It would have been obvious to one of ordinary skill in the art just prior to the filing of the claimed invention to combine the teaching of Jones with that of Maibach in order to improve security, as taught by Jones; [0108] further, it is simply a substitution of known parts for others with predictable results, simply storing Jones’ user code in place of, or in addition to, Maibach’s user data, and obtaining invoice data by the means of Jones rather than those of Maibach; the substitutions produce no new and unexpected result.
With regard to Claim 17:
Maibach teaches: A non-transitory storage medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform: [Col. 49, lines 17-20; “computer-executable instructions stored on one or more computer-readable storage media that, when executed by processor(s), perform the recited operations”]
based on an access instruction of a user for a target service, [Col. 28, lines 17-18; a user makes a purchase from a merchant using a device, and the system tracks data corresponding to the purchase such as “purchase amount” and date and time of purchase; Col. 27, line 34; the merchant may offer “goods or services”] generating a service code creation request comprising service access information… and sending the service code creation request to a service platform; [Col. 29, lines 47-48, the system may create a “one-time code” to send to a “server computing device” in response to a card swipe or other means for accessing a payment card]
performing service code rendering based on service code information returned after the service platform performs service code creation, and sending a rendered service code corresponding to the access instruction to the user; [id.; the one-time code is matched with a copy maintained elsewhere; Col. 30, line 3; the computers “exchange payment information and transaction data”, any of which read on an access instruction or a service code]
performing payment processing based on a payment request submitted after a merchant terminal scans the service code… after payment succeeds [Col. 24, lines 30-31; the POS device “scans a QR code” and then, line 44-45, sends “an indication of the scan to the payment service”, which reads on a step in the performance of payment processing; abstract; the payment may have been “processed using the wireless payment reader”] and
sending the invoice application information to the merchant terminal to perform invoice issuance. [Col. 38, lines 43-45; “payment data can be transmitted to the server computing device(s) 1002 and/or the server computing device(s) 1010 for processing”; the payment data reads on invoice application information; the phrase “to perform invoice issuance” is merely a statement of manner of use which is considered but given no patentable weight]
Maibach does not explicitly teach that a code comprises a user identity identifier, or reading invoice application information associated with a service code identifier comprised in the payment request, but it is known in the art. Jones teaches a reconciliation processing system [title] in which a “unique customer identifier” is associated with a user. [0044] The user identifier may be a numeric code such as “3108”. [0049] The system may “parse” elements of “formatted invoice data” to obtain payment information, [0045] and may execute a “real-time payment” once approved by a user. [0051] It may send confirmation data based on an approval of a payment. [0028] It may “validate” any portion of a message and, in response, generate, send and receive confirmation of a payment. [0051] Jones and Maibach are analogous art as each is directed to electronic means for managing payments.
It would have been obvious to one of ordinary skill in the art just prior to the filing of the claimed invention to combine the teaching of Jones with that of Maibach in order to improve security, as taught by Jones; [0108] further, it is simply a substitution of known parts for others with predictable results, simply storing Jones’ user code in place of, or in addition to, Maibach’s user data, and obtaining invoice data by the means of Jones rather than those of Maibach; the substitutions produce no new and unexpected result.
Claim(s) 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Maibach et al. in view of Jones et al. further in view of Fitch et al. (U.S. Patent No. 8,117,071).
With regard to Claim 5:
The service processing method according to claim 4, after receiving the service code identifier returned after the service platform creates the service code record based on the service request, further comprising:
reading the service code identifier associated with the user identifier based on invoice application keywords submitted by the user; and
generating the invoice application information based on the invoice application keywords, and establishing an association relationship between the invoice application information and the service code identifier.
Maibach and Jones teach the method of claim 4 but do not explicitly teach this use of keywords, but it is known in the art. Fitch teaches a point-of-sale query system [title] which may be used to collect a payment. [Col. 4, lines 9-10] It may generate a “sales invoice” and may determine information based on a “keyword” associated with an unknown product. [Col. 4, line 65] It may read “bar code data” associated with the unknown product. [Col. 5, lines 14-15] This may be done based on a “request for payment” which results in a transmission of the invoice. [Col. 11, lines 21-22] Fitch and Maibach are analogous art as each is directed to electronic means for managing payments.
It would have been obvious to one of ordinary skill in the art just prior to the filing of the claimed invention to combine the teaching of Fitch with that of Maibach and Jones in order to improve efficiency of transactions involving missing data, as taught by Fitch; [See generally BACKGROUND OF INVENTION] further, it is simply a substitution of one known part for another with predictable results, simply using Fitch’s keywords in place of, or in addition to, Maibach’s data to determine what has been sold; the substitution produces no new and unexpected result.
With regard to Claim 6:
The service processing method according to claim 5, wherein the generating the invoice application information based on the invoice application keywords, and establishing the association relationship between the invoice application information and the service code identifier comprises:
generating an information generation request based on the invoice application keywords and the service code identifier, and sending the information generation request to a management platform; wherein the management platform generates the invoice application information based on the invoice application keywords, and establishes an association relationship between an information identifier of the invoice application information and the service code identifier; and
returning an information generation result to the user based on the information identifier returned by the management platform. [Fitch, Col. 11, lines 21-22 as cited above in regard to claim 5]
Claim(s) 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Maibach et al. in view of Jones et al. further in view of Kurani et al. (U.S. Patent No. 11,270,277, filed 3 January 2019).
With regard to Claim 13:
The service processing method according to claim 12, wherein the performing payment processing based on the payment request submitted after the merchant terminal scans the service code comprises:
sending, to a payment platform, the payment request submitted by the merchant terminal when payment information matches the service scenario information, wherein the payment platform performs payment verification on the payment information in the payment request, and performs payment processing after verification succeeds.
Maibach and Jones teach the method of claim 12, including the use of payment requests and sending data about payments between computers, as cited above in regard to claim 1, but do not explicitly teach paying after verification, but it is known in the art. Kurani teaches a bill payment system [title] in which a payment is made “responsive to receiving [a] verification”. [abstract] The verification includes receiving an “amount verification”. [Col. 1, lines 45-46] The verification is a part of a “process flow” to pay a bill. [Col. 12, lines 39-40] It includes verifying and receiving a notice that the “amount is correct”. [Col. 17, lines 17-18] Kurani and Maibach are analogous art as each is directed to electronic means for managing payments.
It would have been obvious to one of ordinary skill in the art just prior to the filing of the claimed invention to combine the teaching of Kurani with that of Maibach and Jones in order to improve user convenience, as taught by Kurani; [Col. 3, lines 61-61; Col. 4, lines 13-19] further, it is simply a substitution of one known part for another with predictable results, simply using Kurani’s process for determining to make a payment in place of, or in addition to, that of Maibach; the substitution produces no new and unexpected result.
With regard to Claim 14:
The service processing method according to claim 13, wherein the payment verification comprises:
determining a payment scenario based on the payment information, and reading payment scenario information corresponding to the payment scenario in the service scenario information; and
performing admission verification on the payment request based on the payment scenario information and the payment information, wherein the performing the admission verification on the payment request comprises:
verifying whether a payment amount in the payment information is less than or equal to a scenario admission amount in the payment scenario information; and determining that verification succeeds in response to verifying that the payment amount in the payment information is less than or equal to the scenario admission amount in the payment scenario information. [Kurani, as cited above in regard to claim 13; that a payment amount is “correct” reads on it being equal to the expected amount]
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT C ANDERSON whose telephone number is (571)270-7442. The examiner can normally be reached M-F 9:00 to 5:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SCOTT C ANDERSON/Primary Examiner, Art Unit 3694