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 Claims
Claims 1 and 10 were amended in the response filed December 15, 2025.
Claims 1-18 are pending.
Claims 1-18 are rejected.
Detailed rejections begin on page 3.
Response to Arguments begin on page 24.
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-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more. The claims recite an abstract idea. This judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
The steps for determining eligibility under 35 U.S.C. 101 can be found in the MPEP § 2106.03-2106.05.
Under Step 1, the claims are directed to statutory categories. Specifically, the method, as claimed in claims 1-9, is directed to a process. Additionally, the computing device, as claimed in claims 10-18, is directed to a machine.
While the claims fall within statutory categories, under Step 2A, Prong 1, the claimed invention recites the abstract idea of requesting offers. Specifically, representative claim 1 recites the abstract idea of:
receiving, at a first node of a plurality of nodes forming a decentralized content distribution system, an inbound content request from an entry one of the nodes, the inbound content request including inbound search parameters derived from a client request received at the entry node from a client;
generating local content, the local content defining goods and services supplied by the first node, and corresponding to the inbound search parameters;
selecting a further one of the nodes, the selection based on the inbound content request and a plurality of node profiles containing respective attribute sets corresponding to each of the plurality of nodes;
prior to transmitting the local content to the entry node, transmitting an outbound content request to the selected further node, the outbound content request containing outbound search parameters based on the inbound search parameters;
receiving, from the further node, subsidiary content corresponding to the outbound search parameters, the subsidiary content defining further goods and services supplied by the further node; and
generating and transmitting, to the entry node, a response to the inbound content request, the response including an offer identifier, the local content, and at least a portion of the subsidiary content.
Under Step 2A, Prong 1, it is necessary to evaluate whether the claim recites a judicial exception by referring to subject matter groupings articulated in the guidance. When considering MPEP §2106.04(a), the claims recite an abstract idea. For example, representative claim 1 recites the abstract idea of requesting offers, as noted above. This concept is considered to be a certain method of organizing human activity. Certain methods of organizing human activity are defined in the MPEP as including “fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).” MPEP §2106.04(a)(2) subsection II. In this case, the abstract idea recited in representative claim 1 is a certain method of organizing human activity because generating and transmitting, to the entry node, a response to the inbound content request, the response including an offer identifier and at least a portion of the subsidiary content is a sales activity. Thus, representative claim 1 recites an abstract idea.
The recited limitations of representative claim 1 also recite an abstract idea because they are considered to be mental processes. As described in the MPEP, mental processes are “concepts performed in the human mind (including an observation, evaluation, judgment, opinion)”. MPEP §2106.04(a)(2) subsection III. In this case, receiving, at a first node of a plurality of nodes forming a decentralized content distribution system, an inbound content request from an entry one of the nodes, the inbound content request including inbound search parameters derived from a client request received at the entry node from a client and receiving, from the further node, subsidiary content corresponding to the outbound search parameters, the subsidiary content defining further goods and services supplied by the further node are types of observation. Additionally, generating local content, defining goods and services supplied by the first node, and corresponding to the inbound search parameters; selecting, based on the inbound content request and a set of node profiles corresponding to the plurality of nodes, a further one of the nodes; prior to transmitting the local content to the entry node, transmitting an outbound content request to the selected further node, the outbound content request containing outbound search parameters based on the inbound search parameters; and generating and transmitting, to the entry node, a response to the inbound content request, the response including an offer identifier and at least a portion of the subsidiary content are types of judgement. Thus, representative claim 1 recites an abstract idea.
Under Step 2A, Prong 2, if it is determined that the claims recite a judicial exception, it is then necessary to evaluate whether the claims recite additional elements that integrate the judicial exception into a practical application of that exception. See MPEP §2106.04(d). In this case, representative claim 1 includes additional elements such as a computing device and a client computing device.
Although reciting additional elements, the additional elements do not integrate the abstract idea into a practical application because they merely amount to no more than an instruction to apply the abstract idea using a generic computer or merely use a computer as a tool to perform the abstract idea. These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration. Similar to the limitations of Alice, representative claim 1 merely recites a commonplace business method (i.e., requesting offers) being applied on a general purpose computer. See MPEP §§2106.04(d) and 2106.05(f). Thus, the claimed additional elements are merely generic elements and the implementation of the elements merely amounts to no more than an instruction to apply the abstract idea using a generic computer. Since the additional elements merely include instructions to implement the abstract idea on a generic computer or merely use a generic computer as a tool to perform an abstract idea, the abstract idea has not been integrated into a practical application. As such, representative claim 1 is directed to an abstract idea.
Under Step 2B, if it is determined that the claims recite a judicial exception that is not integrated into a practical application of that exception, it is then necessary to evaluate the additional elements individually and in combination to determine whether they provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself). See MPEP §2106.05.
In this case, as noted above, the additional elements recited in independent claim 1 are recited and described in a generic manner merely amount to no more than an instruction to apply the abstract idea using a generic computer or merely use a generic computer as a tool to perform an abstract idea.
Even when considered as an ordered combination, the additional elements of representative claim 1 do not add anything that is not already present when they considered individually. In Alice, the court considered the additional elements “as an ordered combination,” and determined that “the computer components ... ‘ad[d] nothing ... that is not already present when the steps are considered separately’ and simply recite intermediated settlement as performed by a generic computer.” Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 573 U.S. 208, 224, 110 USPQ2d 1976, 1983-84 (2014). (citing Mayo, 566 U.S. at 79, 101 USPQ2d at 1972). Also see MPEP §2106.05(f). Similarly, when viewed as a whole, representative claim 1 simply conveys the abstract idea itself facilitated by generic computing components. Therefore, under Step 2B, there are no meaningful limitations in representative claim 1 that transforms the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
As such, representative claim 1 is ineligible.
Dependent claims 2-9 do not aid in the eligibility of independent claim 1. For example, claims 4-5 and 8 merely further define the abstract limitations of claim 1. Also, claims 2-3, 6-7, and 9 merely provide further embellishments of the abstract limitations recited in independent claim 1.
Additionally, it is noted that claims 2-8 do not include further additional elements not already recited in claim 1. Therefore, the claims do not integrate the abstract idea into a practical application because they merely amount to using a generic computer as a tool to perform an abstract idea. The claims also do not amount to significantly more than the abstract idea because they merely amount to using a generic computer as a tool to perform an abstract idea.
Furthermore, it is noted that claim 9 includes additional elements of digitally signing. However, these additional elements do not integrate the abstract idea into a practical application because they merely amount to using a generic computer as a tool to perform an abstract idea. These additional elements are merely generic elements and are likewise described in a generic manner in Applicant’s specification. Additionally, the additional elements do not amount to significantly more because they merely amount to using a generic computer as a tool to perform an abstract idea.
Thus, dependent claims 2-9 are also ineligible.
Lastly, the analysis above applies to all statutory categories of invention. Although literally invoking a machine, claims 10-18 remain only broadly and generally defined, with the claimed functionality paralleling that of claims 1-9. It is noted that claim 10 includes additional elements of a computing device comprising: a memory; a communications interface; and a processor. However, these additional elements do not integrate the abstract idea into a practical application because they merely amount to using a generic computer as a tool to perform an abstract idea. These additional elements are merely generic elements and are likewise described in a generic manner in Applicant’s specification. Additionally, the additional elements do not amount to significantly more because they merely amount to using a generic computer as a tool to perform an abstract idea. As such, claims 10-18 are rejected for at least similar rationale as discussed above.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 8-14, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Chiodini (US 11321642 B1, herein referred to as Chiodini), in view of Crites (US 9519925 B2, herein referred to as Crites).
Claim 1:
Chiodini discloses:
A method {Chiodini: [Col. 2, ln. 3-4] a method for a decentralized rideshare service}, comprising:
receiving, at a computing device implementing a first node of a plurality of nodes forming a decentralized content distribution system, an inbound content request from an entry one of the nodes, the inbound content request including inbound search parameters derived from a client request received at the entry node from a client computing device {Chiodini: fig 1 mobile device 12 (i.e., client computing device), web server 10 (i.e., first node); fig 2 shows rider app (i.e., entry node) [Col. 3, ln. 34-50] a rider user accessing the system (i.e., via the app or entry node) through a mobile computing device 12. The rider user is generally connected to driver users through a wireless network connection 14. The wireless network connection 14 may be through a cloud service or other network but is generally a decentralized network of computing devices (i.e., plurality of devices hosting apps, or nodes). There may be a web-based server 10 (i.e., first node of a plurality of nodes) which provides user registration and access to the service; [Col. 5, ln. 10-11] the rider requests a ride and may input their current location; [Col. 5, ln. 58-62] as a host server, the computing device 600 may also coordinate ride requests and forward acceptance or declines in service from a rider or driver to the other party};
generating local content at the computing device implementing the first node, the local content defining services supplied by the first node corresponding to the inbound search parameters {Chiodini: fig 2, rider I/O; [Col. 3, ln. 56-60] software application may include user interfaces which may be different for driver users than it is for rider users; [Col. 5, ln. 25-29] The rider user may be presented with metadata associated with listed drivers that may assist the rider with selecting one driver over another. The metadata may include driver features or amenities available with the ride service offered. Examiner interprets the content on the rider user interface as local content.};
selecting a further one of the nodes at the computing device, the selection based on the inbound content request and a plurality of node profiles containing respective attribute sets corresponding to each of the plurality of nodes {Chiodini: [Col. 5, ln. 14-20] From the driver user's perspective, the method may include one or more pre-set user defined profiles indicating availability. The system may locate drivers which match up with the user's location; [Col. 5, ln. 1-2] The host platform may access its database of drivers to locate available drivers to meet the request; [Col. 5, ln. 45-47] Each computing device 600 (i.e., further node) may be accessed by a host server (i.e., first node of a plurality of nodes) to match ride requestors with available drivers. Examiner interprets that there are multiple driver computing devices that make up the plurality of nodes, and each driver has a profile indicating their attribute sets.};
prior to transmitting the local content to the entry node, transmitting an outbound content request to the selected further node, the outbound content request containing outbound search parameters based on the inbound search parameters {Chiodini: fig 2, driver app; [Col. 5, ln. 45-47] Each computing device 600 (i.e., hosting driver app, or further node) may be accessed by a host server (i.e., first node of a plurality of nodes) to match ride requestors with available drivers; [Col. 5, ln. 29-31] system may locate one or more available drivers which offer one or more of the features based on their profile settings; [Col. 5, ln. 23-25] drivers may be listed based on a distance setting according to a rider filter setting which matches a driver's filter setting for distance. Examiner interprets that available drivers are found by the server by accessing the driver data via the driver app, which occurs before the rider is presented with available drivers.};
receiving, at the computing device from the further node, subsidiary content corresponding to the outbound search parameters, the subsidiary content defining further services supplied by the further node {Chiodini: [Col. 4, ln. 34-37] A driver user may generate a plurality of pre-set profiles which may offer different rates and features. One or more of the profiles may be selectably enabled by the driver to indicate availability; [Col. 5, ln. 30-34] The system may first check if the driver accepts the ride request. If the driver accepts the request, the driver picks up the ride requestor; [Col. 5, ln. 58-62] a host server may also coordinate ride requests and forward acceptance or declines in service from a rider or driver to the other party; [Col. 5, ln. 25-29] The rider user may be presented with metadata associated with listed drivers that may assist the rider with selecting one driver over another. The metadata may include driver features or amenities available with the ride service offered. Examiner interprets that the rider receives the acceptance from the driver}; and
at the computing device, generating and transmitting, to the entry node, a response to the inbound content request, the response including an offer identifier and at least a portion of the subsidiary content {Chiodini: [Col. 5, ln. 58-62] a host server may also coordinate ride requests and forward acceptance or declines in service from a rider or driver to the other party; [Col. 4, ln. 6-10] The driver's UI may include input fields which receive user defined metadata associated with the driver's rideshare service offerings. For example, the driver may set their own fare associated rates; [Col. 5, ln. 25-29] The rider user may be presented with metadata associated with listed drivers that may assist the rider with selecting one driver over another. The metadata may include driver features or amenities available with the ride service offered.}.
Although disclosing, Chiodini does not disclose:
generating local content, the local content defining goods and services supplied by the first node, and corresponding to the inbound search parameters; and
the subsidiary content defining further goods and services supplied by the further node.
Chiodini does disclose rideshare services that include features and amenities (Chiodini: [Col. 5, ln. 25-29]).
However, Crites teaches:
generating local content, defining goods and services supplied by the first node, and corresponding to the inbound search parameters {Crites: [Col. 2, ln. 24-27] allow users to view, filter and search product and service listings, easily indicate favorite and preferred product and service categories, vendors and specific products; [Col. 1, ln. 53-61] decentralized peer-to-peer digital marketplace may also lend itself to local, personal, “one-off” transactions. Such an informal, ad hoc marketplace also facilitates transactions for services (such as plumbers, dentists, attorneys, lawn care or massage), home-grown produce, local restaurants and food service providers (such as pizza or other “take-out” foods), close-outs, excess inventory, arts and crafts, and many other locally produced and consumed items; [Col. 5, ln. 14-20] publishing the listing 103 may comprise allowing other nodes of the marketplace network to search the one or more listings in storage on the publishing node in an effort to find a listing of interest. In one embodiment, publishing the listing may comprise incorporating the node address of the publishing node (aka publishing node address) into the listing.}; and
the subsidiary content defining further goods and services supplied by the further node {Crites: [Col. 2, ln. 24-27] allow users to view, filter and search product and service listings, easily indicate favorite and preferred product and service categories, vendors and specific products; [Col. 5, ln. 14-20] publishing the listing 103 may comprise allowing other nodes of the marketplace network to search the one or more listings in storage on the publishing node in an effort to find a listing of interest. In one embodiment, publishing the listing may comprise incorporating the node address of the publishing node (aka publishing node address) into the listing}.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included goods from the nodes corresponding to the search parameters as taught by Crites in the decentralized rideshare method of Chiodini in order to lend itself to local, personal, “one-off” transactions, for both new and used products (Crites: [Col. 1, ln. 54-55]).
Claim 2:
Chiodini and Crites teach the method of claim 1. Chiodini further discloses:
wherein selecting the further node includes retrieving an identifier of the further node from a set of preferred node profiles stored at the computing device {Chiodini: [Col. 5, ln. 1-2] The host platform may access its database of drivers to locate available drivers to meet the request; [Col. 4, ln. 6-31] The driver's may include input fields which receive user defined metadata associated with the driver's rideshare service offerings. Fields may be configured to receive driver features including user defined tags which may describe features or limitations of riders preferences available for a ride. The system may locate one or more available drivers which offer one or more of the features based on their profile settings.}.
Claim 3:
Chiodini and Crites teach the method of claim 1. Chiodini further discloses:
wherein selecting the further node includes transmitting a query to a node directory accessible to each of the plurality of nodes and containing a set of node profiles {Chiodini: fig 1, database 20; [Col. 5, ln. 1-2] The host platform may access database of drivers to locate available drivers to meet the request; [Col. 5, ln. 41-47] database repositories 630 of each computing device 600 is spread across several nodes (computing devices 600) on a peer-to-peer network, where each computing device 600 may be accessed by a host server to match ride requestors with available drivers; [Col. 3, ln. 63-64] Respective user types may generally input data including their profile, current location}.
Claim 4:
Chiodini and Crites teach the method of claim 3. Chiodini does not disclose:
storing a predetermined network identifier corresponding to the further node; and
retrieving the predetermined network identifier to transmit the query.
Chiodini does disclose a central server and transmitting a query to the server’s database to find drivers corresponding to a rider request (Chiodini: [Col. 5, ln. 1-2]).
However, Crites teaches:
storing a predetermined network identifier corresponding to the further node {Crites: [Col. 3, ln. 32-38] each node of the peer-to-peer network may have a unique network address for network communication purposes; [Col. 3, ln. 43-46] each node in the marketplace network may comprise a node table 120 (i.e., central repository) that catalogs one or more nodes of the peer-to-peer network; [Col. 3, ln. 61-63] each entry in the node table 120 may comprise a network address. Each entry in the node table 120 may comprise a node ID.}; and
retrieving the predetermined network identifier to transmit the query {Crites: [Col. 3, ln. 61-67; Col. 4, ln. 1-6] each entry in the node table 120 may comprise a network address. Each entry in the node table 120 may comprise a node ID. Each entry in the node table 120 may comprise at least one descriptor. The descriptor in the node table 120 may comprise a node digital signature so any client software may authenticate the node ID of the descriptor; [Col. 8, ln. 40-44] a shopping node 105 may request the remote node table of a node of the peer-to-peer network and search the listings that have been published by one or more of the nodes cataloged in the remote node table.}.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included a unique network address for the nodes as taught by Crites in the decentralized rideshare method of Chiodini in order to offer the user greater privacy and greater anonymity (Crites: [Col. 1, ln. 24-25]).
Claim 5:
Chiodini and Crites teach the method of claim 1. Chiodini further discloses:
wherein generating the response includes generating an offer including the subsidiary content encapsulated within the local content {Chiodini: fig 2, rider I/O; [Col. 3, ln. 25-30] Driver users set their own rates and offer individualized rideshare features through a user interface that is configured for the driver to input user defined features including rates, distances, and other miscellaneous features that may be wanted by a rider; [Col. 5, ln. 25-29] The rider user may be presented with metadata associated with listed drivers. The metadata may include driver features available with the ride service offered; [Col. 5, ln. 58-62] a host server may coordinate ride requests and forward acceptance in service from a driver to a rider}.
Claim 8:
Chiodini and Crites teach the method of claim 1. Chiodini further discloses:
receiving, from the entry node, a booking request including the offer identifier and the local content {Chiodini: [Col. 5, ln. 23-30] drivers may be listed based on a distance setting according to a rider filter setting which matches a driver's filter setting for distance. The rider user may also be presented with other metadata associated with listed drivers that may assist the rider with selecting one driver over another. The metadata may include driver features or amenities available with the ride service offered. The rider selects a driver from the list};
transmitting a subsidiary booking request to the further node identifying the subsidiary content {Chiodini: [Col. 5, ln. 30-31] The rider selects a driver from the list and the selected driver is notified; [Col. 5, ln. 58-62] a host server may coordinate ride requests and forward acceptance in service from a rider to the driver.};
receiving a booking confirmation from the further node {Chiodini: [Col. 5, ln. 58-62] host server may coordinate ride requests and forward acceptance in service from a driver to the rider; [Col. 5, ln. 30-34] The system may first check if the driver accepts the ride request. If the driver accepts the request, the driver picks up the ride requestor}; and
returning the booking confirmation to the entry node {Chiodini: [Col. 5, ln. 58-62] a host server may coordinate ride requests and forward acceptance in service from a driver to the rider}.
Claim 9:
Chiodini and Crites teach the method of claim 8. Chiodini does not disclose:
wherein the booking confirmation includes the subsidiary content, digitally signed by the further node.
Chiodini does disclose sending an acceptance of a ride (i.e., booking confirmation) from a driver to a rider with the corresponding details (i.e., subsidiary content) (Chiodini: [Col. 5, ln. 58-62]).
However, Crites teaches:
the subsidiary content, digitally signed by the further node {Crites: [Col. 4, ln. 64-67] a listing may comprise an item description, a market ID (aka listing market ID) of the listing user, and a digital signature (aka listing digital signature) of the listing user 126 (i.e., further node)}.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included digital signatures for the nodes as taught by Crites in the decentralized rideshare method of Chiodini in order to offer the user greater privacy and greater anonymity (Crites: [Col. 1, ln. 24-25]).
Regarding claims 10-14 and 17-18, claims 10-14 and 17-18 are directed to a machine. Claims 10-14 and 17-18 recite limitations that are parallel in nature to those addressed above for claims 1-5 and 8-9, which are directed towards a method. Therefore, claims 10-14 and 17-18 are rejected for the same reasons as set forth above for claims 1-5 and 8-9, respectively.
It is noted that claim 10 includes additional elements of:
A computing device implementing a first node of a plurality of nodes forming a decentralized content distribution system, comprising:
a memory;
a communications interface; and
a processor configured to perform.
Chiodini discloses:
A computing device implementing a first node of a plurality of nodes forming a decentralized content distribution system {Chiodini: fig 8, decentralized computer system; fig 9; [Col. 5, ln. 56-58] a computer server hosting access to the user interfaces from the rider and driver side interfaces}, comprising:
a memory {Chiodini: fig 9, memory 620};
a communications interface {Chiodini: fig 9, I/O 660; [Col. 6, ln. 52-54] computing device, through the I/O interface/ports 660, may communicate with one or more networks}; and
a processor configured to perform{Chiodini: fig 9, processing unit 610; [Col. 6, ln. 3-10] The components of the computing device 600, may include one or more processing units 610, a computer program product 640 having a set of program modules 645 including files and executable instructions, and a bus system that couples various system components including the system memory 620 to the processor(s) 610.}.
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Chiodini (US 11321642 B1, herein referred to as Chiodini), in view of Crites (US 9519925 B2, herein referred to as Crites), in further view of Paul et. al. (US 20160012461 A1, herein referred to as Paul).
Claim 6:
Chiodini and Crites teach the method of claim 1. Chiodini does not disclose:
wherein the subsidiary content includes further subsidiary content encapsulated therein, received at the further node from an additional one of the plurality of nodes.
Chiodini does disclose a decentralized computing system with a plurality of nodes (Chiodini: fig 8).
However, Paul teaches:
wherein the subsidiary content includes further subsidiary content encapsulated therein, received at the further node from an additional one of the plurality of nodes {Paul: [0017] The second passenger may use the software application on the second passenger's computing device (i.e., additional node) to send a request to join the shared transportation service between the first passenger and the driver. The driver may choose to accept the second passenger's request to join the shared transportation service via the driver's computing device (i.e., further node); [0018] The transportation server establishes the shared transportation service between the driver, the first passenger and the second passenger. The transportation server sends shared transportation service data (i.e., further subsidiary content) to the first passenger's computing device and the second passenger's computing device.}.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included displaying the ride as a shared ride to the first user as taught by Paul in the decentralized rideshare method of Chiodini and Crites in order to provide transportation discounts for multiple passengers of a shared transportation service (Paul: [0030]).
Regarding claim 15, claim 15 is directed to a machine. Claim 15 recites limitations that are parallel in nature to those addressed above for claim 6, which is directed towards a method. Therefore, claim 15 is rejected for the same reasons as set forth above for claim 6.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Chiodini (US 11321642 B1, herein referred to as Chiodini), in view of Crites (US 9519925 B2, herein referred to as Crites), in further view of Handler et. al. (US 20210241185 A1, herein referred to as Handler).
Claim 7:
Chiodini and Crites teach the method of claim 1. Chiodini further discloses:
wherein the subsidiary content includes (i) data defining goods or services supplied by the further node {Chiodini: [Col. 5, ln. 58-62] a host server may also coordinate ride requests and forward acceptance or declines in service from a rider or driver to the other party; [Col. 5, ln. 25-29] The rider user may be presented with metadata associated with listed drivers that may assist the rider with selecting one driver over another. The metadata may include driver features or amenities available with the ride service offered.}.
Although disclosing providing ride offer content from a driver to a rider seeking a ride based on the driver rate, location, and amenities, Chiodini does not disclose:
wherein the subsidiary content includes (ii) data defining commercial terms between the first node and the further node; and
wherein the response omits the data defining the commercial terms.
Chiodini does disclose a decentralized computing system with a plurality of nodes (Chiodini: fig 8) that provides responses to ride requests from drivers (Chiodini: [Col. 5, ln. 58-62]).
However, Handler teaches:
wherein the subsidiary content includes (ii) data defining commercial terms between the first node and the further node {Handler: [0053] the second cost of each reservation service may be a dedicated, pre-negotiated cost that is changed on an annual or monthly basis and is provided by contract between the reservation services system 124 and the corresponding reservation service (e.g., the hotel or theater).}; and
wherein the response omits the data defining the commercial terms {Handler: [0053] The second cost may remain hidden from view from the subscribers of the reservation services system 124 as this cost is incurred internally.}.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included pre-negotiated costs hidden from the subscribers as taught by Handler in the decentralized rideshare method of Chiodini and Crites in order to offer more travel flexibility to users of a subscription-based reservation services system (Handler: [0014]).
Regarding claim 16, claim 16 is directed to a machine. Claim 16 recites limitations that are parallel in nature to those addressed above for claim 7, which is directed towards a method. Therefore, claim 16 is rejected for the same reasons as set forth above for claim 7.
Response to Arguments
With respect to the rejections under 35 U.S.C. 101, Applicant’s arguments have been considered but are not persuasive. However, in view of the amendments, new grounds of rejection have been applied. These new grounds of rejection have been necessitated by Applicant’s amendments.
With respect to pages 6-7 of the Remarks, Applicant argues “the claimed system improves the performance of the content delivery system by permitting additional nodes to be discovered automatically, without the need for subjective discovery and assessment of other nodes by the human operator of a given client device,” citing similarities to McRO. However, Examiner respectfully disagrees.
The MPEP at §§ 2106.04(d)1 and 2106.05(a) provides guidance on how to evaluate whether claims recite an improvement in the functioning of a computer or an improvement to other technology or technical field. For example, the MPEP states “the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement.” The MPEP further states that “[t]he specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art,” and that, “conversely, if the specification explicitly sets forth an improvement but in a conclusory manner…the examiner should not determine the claim improves technology.” That is, the claim includes the components or steps of the invention that provide the improvement described in the specification.
With respect to McRO, the claimed improvement, as confirmed by the originally filed specification, was “…allowing computers to produce ‘accurate and realistic lip synchronization and facial expressions in animated characters…’” and it was specifically “…the incorporation of the claimed rules, not the use of the computer, that “improved [the] existing technological process” by allowing the automation of further tasks”. McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299, (Fed. Cir. 2016).
In the instant case, Applicant’s claims do not recite an improvement to the functioning of a computer or other technology beyond applying an abstract idea to a generic computing environment. The claims instead focus “on a process that qualifies as an ‘abstract idea’ for which computers are invoked merely as a tool.” Enfish LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36 (Fed. Cir. 2016). The technology implemented in the claims merely sends and receives data, which is reflective of computers operating in their ordinary capacity, and thus does not integrate a judicial exception into a practical application. MPEP at § 2106.05(f)(2). This is reflected in paragraphs [0016]-[0018] of Applicant’s specification, which describe Applicant’s claimed invention is directed toward solving abstract problems such as searching for content. Although the claims include computer technology, such elements are peripherally incorporated to implement the abstract idea. This is unlike the improvements recognized by the courts in cases such as McRO.
Unlike McRO, the claims of the instant invention do not recite such a specific improvement to computer capabilities. Applicant alleges that the claimed invention allows for the system to automatically discover other nodes without human intervention, but the claims do not reflect the specific technological steps required to achieve this solution. Thus, the instant claims are not directed to improving “the existing technological process” but are directed to improving the commercial and mental task of searching for content. The claimed process is not providing any improvement to another technology or technical field as the claimed process is not, for example, improving the processor and/or computer components that operate the system. Rather, the claimed process is utilizing different data while employing generic computer components operating in their ordinary capacity to improve searching for content, e.g. commercial and mental process. As such, the claims do not recite specific technological improvements, and the rejection is maintained.
With respect to the rejections under 35 U.S.C. 103, Applicant’s arguments have been considered but are not persuasive in view of Chiodini. However, in view of the amendments, new grounds of rejection have been applied. These new grounds of rejection have been necessitated by Applicant’s amendments.
With respect to page 8 of the Remarks, Applicant argues “[e]ven if the server 10 of Chiodini receives ride requests from the mobile computing device 12, the server 10 is not equivalent to the claimed first node, because the mobile computing device 12 does not receive such requests from another client computing device. The mobile computing device 12 of Chiodini is therefore not an entry node.” While Examiner agrees that the entry node is now recited as separate from the client computing device, Chiodini still discloses an entry node via the application operating on the devices (Chiodini: fig 2). The entry node (i.e., rider app) receives the rider information from the client computing device via operation by the rider, and the web server 10 implements the first node via the app’s software (Chiodini: [Col. 3, ln. 49-50]). The driver apps can thus be interpreted as the further nodes operating in conjunction with the driver devices. Therefore, Chiodini discloses the recited claim limitations, and the rejection is maintained.
With respect to page of the Remarks, Applicant argues “office action contends that the outbound content request is a message sent to a driver, to ‘check if the driver accepts the ride request’. Chiodini's system does not send such a request until after the rider has selected a driver, which necessarily involves the rider receiving a response to the rider's initial search.” While Examiner agrees, that such a scenario is not covered by the recited amendments, Chiodini still discloses the claim limitation as amended. The rider in Chiodini’s system sends an outbound request when they are looking for a driver (Chiodini: [Col. 5, ln. 10-11]). The server receives this request and accesses drivers available via the driver app to determine which drivers are available for the ride requestor (Chiodini: [Col. 5, ln. 45-47]). This means that the rider does not receive available driver information (i.e., a response comprising the local content at the entry node), until after the server has determined driver availability via contacting the drivers via the driver app. Therefore, Chiodini does disclose this limitation, and the rejection is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Liu et. al. (US 20100049556 A1) was used to understand other methods for returning travel information to a user when some of the travel data is not under control of the operator of the system.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) 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 KATHERINE A BARLOW whose telephone number is (571)272-5820. The examiner can normally be reached Monday-Friday 10am-6pm EST.
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, Marissa Thein, can be reached on 571-272-6764. 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.
/KATHERINE A BARLOW/Examiner, Art Unit 3689
/VICTORIA E. FRUNZI/Primary Examiner, Art Unit 3689 1/15/2026