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 .
This communication is in response to the remarks and amendments filed on 3 December, 2025.
Claims 1-20 are pending.
Claims 1, 8 and 15 have been amended.
Response to Arguments
35 USC § 103
Regarding amended claim 1 and with reference to the prior art of record (Davis-Mathis), Applicant argues that, “Neither Davis nor Mathis describe custom group instances based on exclusive attributes shared in common by all members of the corresponding user group. Furthermore, neither Davis nor Mathis describe excluding all non-common attributes when deriving custom group instance parameters”. Examiner respectfully disagrees.
The amended limitation of claim 1 recites, “…wherein each user group of the plurality of user groups are defined by a plurality of group parameters, wherein each of the plurality of group parameters is derived exclusively from attributes shared in common by all members of the corresponding user group, and wherein the plurality of group parameters exclude any parameter associated with an attribute not shared by every member of the user group”. Applicant indicated that support for the amended limitation being argued can be found at least in Figures 6A and 14A and paragraphs [0066]-[0069] and [0082]-[0088] of the specification. Examiner finds that Applicant’s limitation is significantly narrower in scope than what is stated in their Specification, and what is being argued. Firstly, Examiner does not agree that the Specification states that the group parameters are derived exclusively from attributes shared in common by all members of the corresponding user group. For example, Applicant’s Specification [0067] states,
In some embodiments, each group of the custom group instance 600A, such as groups 610a and 610b, may include one or more unique parameters, such as group parameters 612a and 612b. In each instance of a group, unique parameters may include, but are not limited to, provider offerings (e.g., a sub-network), plans or services (e.g., global or custom to providers within a sub-network), consumer prices, consumer fees, and third-party payee information. The one or more unique parameters may be created, changed, or updated in response to user interactions with the system. A user may interact with the custom group instance 600A, for example, via a dashboard device 608.
Based on such excerpt from Applicant’s Specification, it can be reasonably interpreted that there can be various unique parameters that can be used for a group instance. Furthermore, there is no mention of “attributes shared in common” in Applicant’s Specification. Therefore, one of ordinary skill in the art can reasonably and broadly interpret that any commonality amongst users in a group such as location, health insurance carrier etc. (as just some examples and as taught in Mathis [0015], [0020]), can be construed as a commonality amongst the users in the group.
Applicant’s amended limitation further recites “…and wherein the plurality of group parameters exclude any parameter associated with an attribute not shared by every member of the user group”. Examiner notes that a group formed on the basis of a commonality amongst the users, would exclude as it’s basis any other attributes that the same users may have. For example, if the basis of the group is a common location, then the fact that the users may be of different genders can be considered an excluded parameter that is not shared/common among every member of the group. Therefore, under broadest reasonable interpretation, whatever factors form the common basis for the group can be the parameters that are derived exclusively from attributes shared in common by all members of the group and whatever is excluded from being common amongst the users, can be excluded as group parameters. Based on such rationale, Examiner ultimately finds Applicant’s arguments unpersuasive and maintains the rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-10 and 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al (US 2014/0095195), in view of Mathis (US 2018/0047120).
Regarding claim 1, Davis teaches a multi-layer adaptive routing (LAR) computing device for the routing of packet data comprising at least one processor in communication with a memory device (Davis Fig.5 provides “…a diagrammatically shows one embodiment of the intelligent router multiple payment method components”), and transmit the data packets to the at least some of the plurality of users based upon the routing information (Davis [0049]).
Davis teaches the above but Davis does not explicitly teach wherein the at least one processor is configured to: store, on a database, a custom group instance including a network of a plurality of service providers and a consultant including a plurality of user groups configured to use services provided by the plurality of service providers, wherein each user group of the plurality of user groups are defined by a plurality of group parameters related to attributes of the group rather than attributes of the plurality of service providers; wherein the plurality of user groups may access the plurality of service providers based upon the corresponding plurality of group parameters; receive a data request from at least one of a plurality of users of one of the plurality of user groups of the custom group instance; submit a query to the database based at least in part on the data request; receive, from the database, a response to the query submitted to the database; determine at least some of the plurality of users within the custom group interface instance to route information in the response to; create, based on the response from the database based on the query, data packets and routing information for the data packets among at least some of plurality of users within the custom group interface instance based upon the determination.
However, in a similar field of endeavor, Mathis teaches to store, on a database, a custom group instance including a network of a plurality of service providers and a consultant including a plurality of user groups configured to use services provided by the plurality of service providers, wherein each user group of the plurality of user groups are defined by a plurality of group parameters, wherein each of the plurality of group parameters is derived exclusively from attributes shared in common by all members of the corresponding user group, and wherein the plurality of group parameters exclude any parameter associated with an attribute not shared by every member of the user group (Mathis [0015] provides “…a method of remotely conveying the location of healthcare providers based on accepted health insurance carrier information, price constraints, and proximity to the location of a user. The present method may be implemented via software stored on a device capable of wirelessly transmitting and receiving information. The method allows users to send their current location to a database having healthcare provider location information stored thereon. The database then transmits a ranked list of healthcare providers to the user based on a series of criteria determined by the user. The method also provides for directing the user to a chosen healthcare provider”, wherein a custom group instance can be broadly interpreted as a grouping on the basis of insurance coverage, location, financial budget etc. and anything that is not common among the users is not considered a group parameter; Mathis [0020] provides “…the ranked list of healthcare providers contains only providers that accept the user's health insurance coverage, fall within the chosen geographic radius of the user's location, meet a rating threshold, and offer desired medical treatment options within a designated price range.”);
wherein the plurality of user groups may access the plurality of service providers based upon the corresponding plurality of group parameters (Mathis [0020] provides “…the ranked list of healthcare providers contains only providers that accept the user's health insurance coverage, fall within the chosen geographic radius of the user's location, meet a rating threshold, and offer desired medical treatment options within a designated price range.”);
receive a data request from at least one of a plurality of users of one of the plurality of user groups of the custom group instance (Mathis [0015] provides “…a method of remotely conveying the location of healthcare providers based on accepted health insurance carrier information, price constraints, and proximity to the location of a user. The present method may be implemented via software stored on a device capable of wirelessly transmitting and receiving information. The method allows users to send their current location to a database having healthcare provider location information stored thereon. The database then transmits a ranked list of healthcare providers to the user based on a series of criteria determined by the user. The method also provides for directing the user to a chosen healthcare provider”);
submit a query to the database based at least in part on the data request (Mathis fig. 2 and [0015] provides “…a method of remotely conveying the location of healthcare providers based on accepted health insurance carrier information, price constraints, and proximity to the location of a user. The present method may be implemented via software stored on a device capable of wirelessly transmitting and receiving information. The method allows users to send their current location to a database having healthcare provider location information stored thereon. The database then transmits a ranked list of healthcare providers to the user based on a series of criteria determined by the user. The method also provides for directing the user to a chosen healthcare provider”);
receive, from the database, a response to the query submitted to the database (Mathis fig. 2 and [0015] provides “…a method of remotely conveying the location of healthcare providers based on accepted health insurance carrier information, price constraints, and proximity to the location of a user. The present method may be implemented via software stored on a device capable of wirelessly transmitting and receiving information. The method allows users to send their current location to a database having healthcare provider location information stored thereon. The database then transmits a ranked list of healthcare providers to the user based on a series of criteria determined by the user. The method also provides for directing the user to a chosen healthcare provider”);
determine at least some of the plurality of users within the custom group interface instance to route information in the response to (Mathis fig. 2 and [0015] provides “…a method of remotely conveying the location of healthcare providers based on accepted health insurance carrier information, price constraints, and proximity to the location of a user. The present method may be implemented via software stored on a device capable of wirelessly transmitting and receiving information. The method allows users to send their current location to a database having healthcare provider location information stored thereon. The database then transmits a ranked list of healthcare providers to the user based on a series of criteria determined by the user. The method also provides for directing the user to a chosen healthcare provider”, wherein some of the plurality of users can be broadly interpreted to be users who requested the information);
create, based on the response from the database based on the query, data packets and routing information for the data packets among at least some of plurality of users within the custom group interface instance based upon the determination (Mathis fig. 2 and [0015] provides “…a method of remotely conveying the location of healthcare providers based on accepted health insurance carrier information, price constraints, and proximity to the location of a user. The present method may be implemented via software stored on a device capable of wirelessly transmitting and receiving information. The method allows users to send their current location to a database having healthcare provider location information stored thereon. The database then transmits a ranked list of healthcare providers to the user based on a series of criteria determined by the user. The method also provides for directing the user to a chosen healthcare provider”).
It would have been obvious to one of ordinary skill in the art at the time of filing to include in the payment method and system of Davis the ability to group users based on parameters so that users and providers are matched in an informed manner.
Regarding claim 2, Davis-Mathis teaches the MLAR computing device of claim 1, wherein the data request is sent to the MLAR computing device in response to an event (Mathis [0019] provides “The logic 15 causes location information of the client computer 11 and a series of criteria entered by a user into a client computer application to be transmitted 23 to a server 21 having a database 22 of healthcare provider information stored on non-transitory memory”). Motivation provided with reference to claim 1.
Regarding claim 3, Davis-Mathis teaches the MLAR computing device of claim 2, wherein the event occurs in response to a data extraction process initiated by one of the at least one of the plurality of users (Mathis [0019] provides “The logic 15 causes location information of the client computer 11 and a series of criteria entered by a user into a client computer application to be transmitted 23 to a server 21 having a database 22 of healthcare provider information stored on non-transitory memory”). Motivation provided with reference to claim 1.
Regarding claim 5, Davis-Mathis teaches the MLAR computing device of claim 2, wherein the event occurs in response to a modification made to the custom group instance (Mathis [0019] provides “The logic 15 causes location information of the client computer 11 and a series of criteria entered by a user into a client computer application to be transmitted 23 to a server 21 having a database 22 of healthcare provider information stored on non-transitory memory”, wherein a change in criteria can be broadly interpreted as a modification). Motivation provided with reference to claim 1.
Regarding claim 6, Davis-Mathis teaches the MLAR computing device of claim 1, wherein the data packets are divided and routed based on a customized plan of the custom group instance (Davis [0003] provides “…there are thousands of medical health insurance plans. Major employers negotiate custom medical insurance plans for their employees. Other companies select one of several insurance plans offered by an insurance company which may or may not include various options. Small business associations negotiate yet other health insurance contracts. The employees within these various employer groups obtain medical services at a plurality of covered medical facilities. Conversely, the various medical facilities treat patients with a myriad of different health plans”).
Regarding claim 7, Davis-Mathis teaches the MLAR computing device of claim 1, wherein the database stores and maintains: a plurality of user records associated with the plurality of users (Davis fig.1); a plurality of provider records associated with a plurality of providers (Davis fig.1); and one or more affiliations between at least some of the plurality of users and some of the plurality of providers based on a customized plan of the custom group instance (Davis [0003], fig.1).
Regarding claim 8, this claim contains limitations found within those of claim 1, and the same rationale of rejection applies, where applicable.
Regarding claim 9, this claim contains limitations found within those of claim 2, and the same rationale of rejection applies, where applicable.
Regarding claim 10, this claim contains limitations found within those of claim 3, and the same rationale of rejection applies, where applicable.
Regarding claim 12, this claim contains limitations found within those of claim 5, and the same rationale of rejection applies, where applicable.
Regarding claim 13, this claim contains limitations found within those of claim 6, and the same rationale of rejection applies, where applicable.
Regarding claim 14, this claim contains limitations found within those of claim 7, and the same rationale of rejection applies, where applicable.
Regarding claim 15, this claim contains limitations found within those of claim 1, and the same rationale of rejection applies, where applicable.
Regarding claim 16, this claim contains limitations found within those of claim 2, and the same rationale of rejection applies, where applicable.
Regarding claim 17, this claim contains limitations found within those of claim 3, and the same rationale of rejection applies, where applicable.
Regarding claim 18, this claim contains limitations found within those of claim 5, and the same rationale of rejection applies, where applicable.
Regarding claim 19, this claim contains limitations found within those of claim 6, and the same rationale of rejection applies, where applicable.
Regarding claim 20, this claim contains limitations found within those of claim 7, and the same rationale of rejection applies, where applicable.
Claims 4 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al (US 2014/0095195), in view of Mathis (US 2018/0047120), further in view of Niemeyer (US 2019/0318431).
Regarding claim 4, Davis-Mathis teaches the MLAR computing device of claim 3, but Davis-Mathis does not explicitly teach wherein the data extraction process includes extracting data from an Electronic Data Interchange (EDI) 834 file.
However, in a similar field of endeavor, Niemeyer teaches wherein the data extraction process includes extracting data from an Electronic Data Interchange (EDI) 834 file (Niemeyer [0039] provides “The episode eligibility system 120 determines the patient eligibility for the clinical episode based on stored eligibility of members that uses eligibility file provided by payors (e.g., the insurance service provider 116). The eligibility file includes health insurance details of the patient 102. The eligibility files may take the form of EDI 834 files, CSV files or some other type of automated feed or API”).
It would have been obvious to one of ordinary skill in the art at the time of filing to include in the payment method and system of Davis-Mathis the ability to utilize EDI 834 files as taught by Niemeyer to allow cross referencing eligibility files as provided by insurance providers (Niemeyer [0039]).
Regarding claim 11, this claim contains limitations found within those of claim 4, and the same rationale of rejection applies, where applicable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ciechanowski US 8,521,564.
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 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 ISHRAT RASHID whose telephone number is (571)272-5372. The examiner can normally be reached 10AM-6PM EST M-F.
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, Tonia L Dollinger can be reached at 571-272-4170. 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.
/I.R/Examiner, Art Unit 2459 /SCHQUITA D GOODWIN/Primary Examiner, Art Unit 2459